HSTS Preload List
The HSTS preload list is a built-in browser roster of domains that must only be reached over HTTPS, closing the first-request downgrade window that HSTS headers alone leave open.
Definition
The preload list is a set of domains compiled into browsers that forces HTTPS from the very first connection. A site joins by sending an HSTS header with the includeSubDomains and preload directives and submitting the domain to the maintainer of the list. It removes the one-shot stripping attack that a plain HSTS header cannot prevent.
Context and scope
Adopted by domains that will never serve plain HTTP again, before enabling HTTP-to-HTTPS redirects, and typically alongside Secure Cookies and upgrade-insecure-requests.
Common misconceptions
- Preload only strengthens your own site — it also permanently pins every subdomain to HTTPS
- You can easily leave the preload list — removal takes months and requires browser release cycles
- Sending the preload directive automatically enrolls you — enrollment requires an explicit submission
Anti-patterns
- Preloading a domain that still hosts an internal plain-HTTP tool or appliance on a subdomain
- Enabling preload before auditing all subdomains and legacy virtual hosts for HTTPS readiness
- Relying on a 301 redirect as equal protection — the first plain-HTTP request is still interceptable
Related concepts
Related examples
Authoritative source
What it is
HSTS headers protect a domain only after the browser has seen one HTTPS response, leaving the very first request open to a downgrade. The preload list removes that bootstrap hole by shipping the policy in the browser itself. Subdomains, apex requirements, and redirect behavior are all part of enrollment criteria.
How it works
The site serves Strict-Transport-Security with max-age, includeSubDomains, and preload, then submits at hstspreload.org. After automated checks, the domain lands in the Chromium-maintained list that other browsers consume. Once shipped, removal requires a deliberate, slow process measured in months.
When to use it
Preload suits domains with HTTPS-only posture forever: public sites, API hosts, login domains. Audit every subdomain first, including forgotten internal tools and printer admin panels. Pair with secure cookie flags so cookies never traverse plaintext either.
Pitfalls
The commitment is near-irreversible, and a single HTTP-only subdomain becomes unreachable once included. Legacy clients pinned to http:// links will fail hard rather than redirect. Rollout order matters: full HTTPS everywhere, then HSTS header with growing max-age, then preload submission.