How to safely remove a domain from the HSTS preload list

Adding a domain to the HSTS preload list takes a form submission and a browser release cycle. Removing it takes the same form and the same release cycle — but the consequences of being on the list while something is broken are far worse, so the removal path is worth understanding before you ever submit. The short version: you can request removal, it is not instant, and there is no button that reaches browsers already in the wild.

Why removal is inherently slow

The preload list is not a service browsers query at runtime. It is a static list compiled from hstspreload.org into the Chromium source tree and shipped inside the browser binary. Firefox, Safari and Edge consume the same list. That architecture is exactly what closes the first-visit gap — the policy is present before a browser has ever contacted your site — but it also means a change to the list only reaches a user when they install a browser update that was built after your change landed.

So a removal has to travel a long pipeline: your request is accepted, the entry is dropped from the source list, that change rides a Chromium release through beta to stable, and then each user updates. Realistically this is measured in months, not days, and a meaningful tail of users on older builds keep the hardcoded entry for longer still. There is no expedited path for the ordinary case.

The removal process, step by step

1. Stop sending the preload directive. Change your header so it no longer contains the preload token. Keep serving HSTS itself — for example Strict-Transport-Security: max-age=31536000; includeSubDomains — you are only dropping the signal that you want to be preloaded. The removal tool will reject your request if it still sees preload in the response.
2. Submit the domain on the removal form. Enter the apex at hstspreload.org and request removal. The site re-checks your header, confirms the preload directive is gone, and queues the domain to be dropped from a future list build.
3. Wait for the release train. The entry is removed when a browser version built after the change ships and the user updates to it. Nothing you do on your own servers accelerates this stage.

What you can — and cannot — do in the interim

While the removal is pending, you have limited but real options, and it is important to be precise about which cache each one clears.

Browsers keep two HSTS sources for your domain: the hardcoded preload entry, and any dynamic policy set by a header the browser saw over HTTPS. Serving Strict-Transport-Security: max-age=0 (keep includeSubDomains if you originally used it) clears the dynamic policy for any visitor who returns over HTTPS and receives that header. It does nothing to the preload entry — that one is baked into the binary and only disappears when the removal ships in that user's browser build.

The practical consequences:

• You cannot rescue a genuinely broken host during the wait. If a subdomain has no valid HTTPS and includeSubDomains is in force via preload, it stays unreachable for preloaded browsers until removal lands. The only real fix is to restore HTTPS on that host — which is almost always faster than removal anyway.
• max-age=0 is still worth serving, because it prevents the dynamic policy from silently re-pinning returning visitors and cleans up those who can reach you over HTTPS.
• Do not simply pull the HSTS header entirely and hope it lapses. Preloaded browsers never consulted your header to begin with; removing it changes nothing for them and removes protection for everyone else.

How to avoid ever needing this

Removal is the wrong problem to get good at. The list is designed to be a durable commitment, and the winning move is to only submit when you are certain you can keep the promise indefinitely.

• Get the whole tree HTTPS-clean first. Because preload requires includeSubDomains, every host under your domain is covered. Inventory them all and confirm each one before you submit — the failure mode is exactly the includeSubDomains trap. Verify handshakes and chains with TLS Studio and certificate validity with SSL Studio.
• Ramp max-age in production before you preload. Live for weeks on a one-year max-age with includeSubDomains and no preload. This is a full dress rehearsal of the preloaded state that you can still walk back by serving max-age=0. If anything is going to break, it breaks here, where recovery takes minutes. Our guide on choosing a max-age value covers the ramp.
• Preload a domain you intend to keep. Submitting a short-lived campaign domain, or a name you might hand back, is how sites end up needing removal. If the domain's future is uncertain, do not preload it.
• Confirm the apex redirect is solid. Preload requires the apex to redirect HTTP to HTTPS and to serve the header on the HTTPS response; a flaky redirect is one more thing that becomes hard to fix once you are locked in. If redirects are part of your setup, Redirects Studio can trace the chain.

Preloading is one of the strongest guarantees you can give your users, and that strength comes precisely from being hard to reverse. Treat the removal process as the emergency exit it is — good to know where it is, better never to need it.

← Back to the HSTS checker