HSTS preload: the submission requirements, the risks and how to check your header and list status

1. What the HSTS preload list is

HTTP Strict Transport Security is defined in RFC 6797. A server sends Strict-Transport-Security: max-age=… over HTTPS, and the browser remembers for max-age seconds that the host may be reached only over HTTPS. Until a visitor’s browser has received that header once, nothing protects the first plain http:// request, and an attacker on the same network can intercept it. The RFC describes this bootstrap weakness and suggests pre-configured policies as one answer.

The preload list is that answer in practice. The Chromium project maintains it and new entries are hard-coded into Chrome’s source code. According to the Chromium HSTS page and hstspreload.org, Firefox, Safari and Edge keep their own lists based on Chrome’s. In every browser version that includes the entry, a preloaded domain is HTTPS-only from the first start, and because submissions must include includeSubDomains, so is every name below it.

Three details are often misunderstood:

• The preload directive does nothing in the browser. It is not part of RFC 6797, and browsers ignore directives they do not recognize. It tells the list maintainers that the domain owner agrees to inclusion. Once your header carries it, anyone can submit your domain through the form.
• Only whole registrable domains go on the list. You submit example.com, not www.example.com or shop.example.com, and the entry covers every subdomain, including internal ones that are not publicly reachable.
• Some top-level domains are preloaded as a whole. Every domain under .app or .dev, for example, is already HTTPS-only in browsers that use the list, whether or not its owner submitted anything.

2. Do you still need preloading?

For most sites, probably not. The submission site itself now says that HSTS is recommended but HSTS preloading is not. Chrome and Safari automatically try HTTPS for navigations that start as http://, whatever the HSTS policy, so the first-visit gap that preloading was built to close has narrowed. According to hstspreload.org, preloading adds protection only when those automatic upgrades fail because of an active attacker, and its benefit is minimal compared with HSTS itself.

Preloading can still make sense when all of these are true:

• a downgrade on the very first visit matters to you, for example because people sign in or pay from public networks;
• every current and future subdomain, including internal and vendor-hosted ones, can serve HTTPS with a valid certificate;
• you plan to keep the domain, and HTTPS on it, for years.

Skip it, or postpone it, if teams or vendors run subdomains you do not fully control, if internal hosts live under the public domain, if the domain belongs to a short-lived campaign, or if you might sell or hand it over: the entry follows the domain to its next owner until someone requests removal. A well-configured HSTS header without preload already protects every returning visitor.

3. The exact submission requirements

hstspreload.org checks these conditions when you submit, and you have to keep meeting them afterwards: domains that stop meeting them may be removed, and dropping preload from the header makes the domain eligible for removal straight away.

The redirect rule catches many sites. If https://example.com/ redirects to https://www.example.com/, that redirect response must carry the full header itself. The header on the www page does not count, because a policy set by www.example.com never applies to the base domain. A header that passes looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. The risks: why preloading is hard to undo

• Removal takes months. Removal is a source change that reaches people with browser updates. The removal page says it can take 6 to 12 weeks to reach most Chrome users, and possibly longer in other browsers. A browser that is never updated keeps the old entry.
• Subdomains that cannot do HTTPS stop working. Typical cases are intranet hosts that resolve only on internal DNS, admin pages of printers, routers and storage devices with self-signed certificates, forgotten staging servers, and vendor services on a CNAME, such as a help desk, a status page or email click-tracking links, that answer only over HTTP. In a browser with your domain preloaded, they fail with no way past the error.
• Certificate mistakes become hard failures. On an HSTS host, RFC 6797 requires the browser to end the connection on any certificate error without letting the visitor click through. An expired certificate on any subdomain locks everyone out until it is replaced, so automate renewal and monitor expiry dates before you submit.
• Returning visitors keep their stored policy. Leaving the list does not clear the policy that browsers learned from your header. With a two-year max-age, that copy lasts two years unless the visitor comes back and receives max-age=0 over HTTPS.
• Accidental submission. A header copied from a template with preload already in it is enough for anyone to submit your domain. Leave the directive out until the plan in the next section is done.

5. A staged max-age plan before you submit

hstspreload.org recommends raising max-age in stages, with includeSubDomains from the first stage. At each stage, look for broken pages and watch your numbers, such as traffic, sign-ins and revenue, fix what comes up, then wait at least the full max-age of that stage before you move on. You can run the stages with a test group first, but then run them for everyone.

On nginx, send the header from the HTTPS server block with the always parameter, so error pages carry it too, and keep the HTTP redirect on the same host. An add_header line inside a location block replaces the server-level headers there (nginx headers module).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # stage 1: change the value at each stage
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

The ramp-up alone takes more than five weeks. After you submit, hstspreload.org says a new entry can take several months to reach stable Chrome, so preloading is never a quick fix for a launch date.

6. How to check your HSTS header

Check the three responses that matter from a terminal:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

The first should return 301 or 308 with Location: https://example.com/; it needs no HSTS header, because browsers ignore HSTS received over plain HTTP. The second must carry strict-transport-security with all three directives, even when it is itself a redirect to www. The third should send the header as well, because a visitor who only ever opens www never receives the base domain’s policy. On Windows, call curl.exe and use -o NUL.

Watch for these mistakes:

• Two HSTS headers. When the CDN and the origin both add one, RFC 6797 tells browsers to process only the first, and the hstspreload.org check reports “Multiple HSTS headers” as an error. Decide which layer owns the header.
• A misspelled directive. Browsers drop directives they do not recognize without any warning, so includeSubdomain without the final s quietly leaves subdomains uncovered.
• Missing on some responses. The home page has the header, but error pages, the API or static files served by another layer do not.

In Chrome DevTools, open the Network panel, then type http://example.com/ into the address bar after the browser has stored the policy. The first entry shows 307 Internal Redirect with Non-Authoritative-Reason: HSTS: the browser switched to HTTPS by itself, before any request reached the server. The MDN reference lists the header syntax.

7. How to check your preload list status

• hstspreload.org. Enter the domain in the form. It shows whether the domain is preloaded, pending or not on the list, along with any errors and warnings against the current requirements. A pending domain is not protected yet: it still has to ship in a browser release.
• chrome://net-internals/#hsts. In Chrome, enter the domain under “Query HSTS/PKP domain”. Fields that start with static_ come from the list built into that browser version; fields that start with dynamic_ come from headers the browser has received. “Delete domain security policies” clears only the dynamic part, so a preloaded entry stays until a browser update removes it.
• Other browsers. Firefox, Safari and Edge ship their own copies derived from Chrome’s list on their own schedules, so an addition or a removal can reach them at different times.

Repeat the check after changes to DNS, your CDN or your certificates. hstspreload.org notes that domains which stop meeting the requirements may be removed automatically in the future.

8. Leaving the list: removal steps and timing

1. Keep serving HTTPS with a valid certificate on the base domain; the removal form checks it.
2. Send an HSTS header without preload. hstspreload.org treats that header as the removal request. Keep includeSubDomains and a long max-age if you still want HSTS, or send max-age=0 to switch HSTS off entirely.
3. Submit the domain on the removal form.
4. While you wait, give the subdomain that forced the decision a valid certificate or move it to another domain: removal can take 6 to 12 weeks to reach most Chrome users and longer for other browsers.
5. Do not send preload again unless you want to be added back.

max-age=0 works only over HTTPS and only for visitors who come back and receive it. Plan for the slowest path: an outdated browser that still has the built-in entry, or a stored two-year policy, can keep enforcing HTTPS long after you have changed course.

9. What the free Launch Readiness Snapshot shows

The free Launch Readiness Snapshot runs eight passive checks on one public domain without signup and returns a score with the result of each check. Two of them look at HSTS:

• The HTTP security headers check reads the home page of the domain you enter, after up to five redirects. It rates a missing Strict-Transport-Security header on an HTTPS target as medium and shows the value it observed.
• The HTTPS redirect check flags a max-age under 180 days (15,552,000 seconds) as low when you enter a bare domain or an https:// address. During stages 1 to 3 of the plan, that result is expected.

It does not check includeSubDomains, the preload directive, your subdomains or your list status; use hstspreload.org and the curl commands above for those. To open the header result first, use the free security headers checker, which runs the same snapshot. For the certificate side, read the guide to TLS certificates and HSTS, and the website launch checklist puts HSTS next to redirects, DNS and the other pre-launch checks.