Glossary

HSTS preload

The HSTS preload list is a set of domains compiled into browsers, so that a browser enforces HTTPS for them before it has ever contacted the site. It closes the one gap an ordinary HSTS header cannot: the very first request from a browser that has never seen the header. Inclusion is voluntary, requires meeting strict conditions, and removal takes months to reach users, so it is a commitment rather than a setting.

What the list is

A list maintained by the Chromium project and consumed, with local modifications, by the other major browsers.

It ships inside the browser binary, so a domain on it is enforced from installation, with no prior visit required.

Submission is through a public form at hstspreload.org, and the conditions are checked automatically at submission.

Because it is compiled into releases, both additions and removals travel at the speed of browser release cycles — measured in weeks to months, not hours.

The conditions for inclusion

A valid certificate, and a redirect from HTTP to HTTPS on the same host if the site serves HTTP at all.

An HSTS header on the HTTPS response with `max-age` of at least one year, plus `includeSubDomains` and `preload`.

Every subdomain must serve HTTPS, because `includeSubDomains` is mandatory and there is no way to exempt one afterwards.

The domain must be a registrable domain — the apex — not a subdomain, for generic top-level domains.

The submission form checks all of this live before accepting, so a domain that does not yet meet the conditions is refused rather than added and later broken.

Why removal is slow

Removal is requested through the same site, and the domain is taken off the list in a subsequent browser release.

Users receive that release when they update, which for a long tail of installations is months later.

Until then, the browser continues to refuse plain HTTP for the domain regardless of what the site serves.

This is the reason the conditions are strict: a domain added carelessly cannot be rescued quickly, and a subdomain that must serve plain HTTP has no exemption available.

Whether it is worth doing

For a site whose entire estate is HTTPS and expected to stay that way, it is a genuine improvement with no ongoing cost.

For an organisation with legacy internal subdomains, devices on the same domain, or systems it does not fully control, it is a trap that will be discovered later.

The intermediate position is a long `max-age` with `includeSubDomains` and no preload submission: almost all the benefit for returning visitors, and reversible within the `max-age` window.

Check current status with `curl -I https://example.com | grep -i strict` for the header, and the preload site's own query form for list membership.

Worth knowing before deciding: the list has grown to include a large share of prominent domains, and it is also used by some non-browser software, so the policy reaches further than browser releases alone.

Frequently asked questions

Do I need to be on the preload list?
No. It closes only the first-ever visit from a browser that has never seen the header. A long max-age covers everything after that and stays reversible.
Can I preload a single subdomain?
Not for generic top-level domains. Submissions are accepted for the registrable domain, and includeSubDomains is mandatory.
How long does removal from the list take?
Months. The change ships in a browser release and only reaches a user when that user updates.

Sources

Related

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website