Reference guide · dns-ssl · Published 2026-08-16 · 3 min read
HSTS preload and the preload list
HSTS preload explained, how the preload list works and differs from the header, and whether your site should be added.
- ·Header vs preload
- ·How to opt in
- ·Before you submit
HSTS (Strict Transport Security) tells a browser, after it visits the site once, to use HTTPS for that domain for a stated period. That requires a first HTTPS visit to take effect, and it is per browser. HSTS preload removes that first-visit catch by hardcoding the domain into a list shipped inside browsers, so HTTPS is enforced from the very first connection, before any header is ever seen. The two are related but different, and preload is a stronger, harder-to-undo commitment.
Header vs preload
| Mechanism | Scope | First visit protected? |
|---|---|---|
| HSTS header only | Each browser that has seen the header | No, needs a prior HTTPS visit |
| HSTS preload | Every browser shipping the list | Yes, from the first request |
The header is a response header set on the server. Preload is a three-step opt-in: your site must serve the header with the preload directive, you submit the domain to the preload list, and a validator checks the requirements before including it. Browsers that carry the list then treat the domain as HTTPS-only even on a cold cache.
How to opt in
- Serve HTTPS everywhere and ensure every HTTP request redirects to the HTTPS version; partial HTTP breaks the requirement.
- Send the preload-capable HSTS header, including the
preloaddirective rather than onlymax-age:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadThe exact terms the validator expects are a max-age of at least a year, includeSubDomains, and the preload directive. See the HSTS header article for the header mechanics and the two-year value typical of a durable policy.
- Submit the domain at the public preload site (hstspreload.org), which runs the validator and, on success, adds the domain to the shared submission list that browser vendors ship in the next releases.
Once listed, HTTPS for your domain is enforced by the browser itself, not by your server or your redirects. That is exactly what makes it strong, and exactly what makes withdrawing from it slow.
Before you submit
Preload is easy to add and slow to remove, because the list is bundled into browser releases. Verify these first:
- Your HTTPS is total: every subdomain your traffic uses, and anything you intend to serve over HTTPS, is reachable over HTTPS with a valid certificate. A broken subdomain means a browser hard-fails it with no server fallback.
- You will not need plain HTTP again: an old device, a payment redirect, or a misconfigured subdomain cannot be served over HTTP once listed, since the browser refuses before the server responds.
- Your redirects are stable: any lingering need to serve a subdomain over HTTP must be resolved, because includeSubDomains drags every subdomain under the policy.
If any condition is uncertain, run the header with the preload directive but hold off on submitting. The header's effect is per browser and reversible; the list registration is the permanent step.
The HTTPS picture beyond preload
Preload sits on top of the wider HTTPS foundation. The http to https redirect article covers moving the whole site, the HTTPS and SEO page explains why HTTPS is treated as a baseline, and a working certificate chain is the precondition for any of it, covered in the handshake article. A domain that already runs total, certificate-correct HTTPS is the only candidate worth preloading, and the header-first path can test that state without the list commitment.