HSTS was standardized in 2012 (RFC 6797), giving sites a way to instruct browsers to only ever connect over HTTPS for a specified duration. The preload list extension followed shortly after, addressing HSTS's one remaining gap — protection on a domain's very first connection, before any HSTS header could have been received.
How the preload list works technically
Rather than depending on a header at all, the preload list is a literal list of domains compiled directly into the source code of Chrome, Firefox, Safari, and other major browsers — meaning HTTPS-only enforcement for preloaded domains ships with the browser itself, before any connection to that domain has ever happened.
Its trade-offs
Because it's baked into shipped browser releases, removal from the preload list is a slow process, taking months to fully propagate — a deliberate trade-off for the strength of guarantee it provides, and the reason preload submission is generally recommended only after HTTPS has proven stable across an entire domain and all its subdomains.
How a domain actually gets added to the hardcoded preload list
Submission to the HSTS preload list happens through a dedicated site, hstspreload.org, that automatically checks a domain's current HSTS header configuration against the required criteria — once approved, the domain is added to a list maintained in the Chromium open-source project's source code, which is then adopted by Chrome, Firefox, Safari, and most other major browsers, since they largely share this same underlying preload list.
Why the preload list is described as effectively permanent
Because the list is compiled directly into browser software rather than fetched dynamically, a domain's inclusion persists across every copy of every browser version that shipped with it — meaning even after a domain requests removal, users running an older, not-yet-updated browser version will continue enforcing the old preload policy until they eventually update, which can take a meaningfully long time across a browser's full install base.
The specific technical criteria a domain must meet before submission
Beyond simply serving the HSTS header, hstspreload.org's automated checker verifies the max-age value meets a minimum threshold (currently one year), that includeSubDomains and preload directives are both present, and that the root domain itself correctly redirects HTTP to HTTPS — submissions failing any of these checks are rejected with specific feedback on what needs correcting first.
Why removal from the list is deliberately made difficult
The preload list's maintainers deliberately designed the removal process to be slower and more involved than addition, on the reasoning that a domain requesting removal (rather than simply letting a normal HSTS header's max-age lapse naturally) is a meaningfully rarer and more carefully-considered action that shouldn't be trivially easy to reverse once a domain has committed to permanent HTTPS enforcement.
A practical checklist before ever considering preload submission
Confirm HTTPS works flawlessly across every subdomain without exception, confirm the HSTS header has been live with a full one-year max-age for a meaningful period without issues, and be genuinely certain no legitimate use case for plain HTTP remains anywhere under the domain — preload's near-permanence makes this a decision worth double-checking rather than rushing.
How HSTS and Certificate Transparency address two structurally different gaps
It's worth distinguishing what HSTS and Certificate Transparency each actually solve: HSTS protects a specific browser-to-domain connection from downgrade after the first successful visit, while CT protects the entire ecosystem's ability to detect fraudulent issuance regardless of any individual visitor's browsing history. Both emerged from the same broader post-2011 push toward closing structural trust gaps, but they operate at genuinely different layers of the overall system.
A closing thought on permanence as a deliberate security design choice
HSTS preloading's deliberate near-permanence is a useful example of security design intentionally trading flexibility for guarantee strength — accepting that a decision is hard to reverse specifically because that irreversibility is what makes the underlying protection meaningful and trustworthy to rely on.
HSTS preloading's deliberate irreversibility is a design choice that trades flexibility for a stronger, more trustworthy guarantee.