What is the HSTS preload list?

It is a list of domains hard-coded into browsers that are always loaded over HTTPS, even on the very first visit. Being on the list closes the gap before the first HSTS header is received, preventing an initial plaintext request that could be hijacked.

What are the preload requirements?

Serve a valid certificate; redirect HTTP to HTTPS on the same host; serve all subdomains over HTTPS; and send a Strict-Transport-Security header on the base domain with max-age of at least 31536000 seconds (one year), the includeSubDomains directive, and the preload directive.

Why must max-age be at least one year?

hstspreload.org requires max-age of 31536000 seconds or more so the policy persists long enough to be meaningful even if a browser falls back to the dynamically-cached value. Shorter durations are rejected for preload, though they still work for ordinary HSTS.

How do I remove a domain from the list?

Change the header to remove the preload directive (and optionally lower max-age), then submit a removal request at hstspreload.org. Removal propagates slowly because it must ship in new browser releases, so preload is effectively a long-term commitment.

Does this validator send my header anywhere?

No. The header is parsed and checked entirely in your browser against the published rules. Nothing is transmitted.

What is the HSTS Preload Requirements Reference?

Reference and validator for the HSTS Strict-Transport-Security header — max-age, includeSubDomains and preload directives — checked against hstspreload.org submission requirements. It runs free in your browser on Gera Tools, with nothing uploaded.

HSTS Preload Requirements Reference

Name: HSTS Preload Requirements Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

HSTS preload requirements

To appear on the browser HSTS preload list, a site’s Strict-Transport-Security header must meet specific rules from hstspreload.org. This reference explains each requirement and includes a validator that checks a header value for max-age, includeSubDomains and the preload directive.

What HSTS does and why preloading matters

Without HSTS, the very first time a user visits your site their browser may send a plain HTTP request — even if all subsequent visits use HTTPS. That first request is the window an attacker needs for a protocol downgrade or SSL-stripping attack. The Strict-Transport-Security header closes this gap for return visitors by telling the browser to always use HTTPS, but the very first visit is still unprotected.

Preloading closes the first-visit gap entirely. Browsers ship with a hard-coded list of domains (the preload list) that must always be loaded over HTTPS, even before the browser has ever seen the site. Once your domain is on that list, no user ever makes a plaintext request, regardless of what they type in the address bar.

How it works

HSTS is sent as a single response header over HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

For preload, hstspreload.org requires max-age of at least one year (31536000), the includeSubDomains directive, and the preload directive — in addition to a valid certificate and HTTP-to-HTTPS redirects. The validator parses the directives, confirms each rule, and reports what is missing.

The five preload requirements in detail

Requirement	What to check
Valid TLS certificate	Serves a certificate that chains to a trusted root; no mixed-content warnings
HTTP redirects to HTTPS	`http://yourdomain.com` returns 301 or 302 to its HTTPS equivalent
All subdomains over HTTPS	Every subdomain that exists must serve valid HTTPS
`max-age` ≥ 31536000	Header must declare one year or more
`includeSubDomains` + `preload` directives	Both tokens must be present in the header

The validator here checks the header syntax; you need to verify the certificate and redirect rules yourself using a browser or curl -I http://yourdomain.com.

Common failure modes

“includeSubDomains” rejected because of a broken subdomain. If mail.yourdomain.com or dev.yourdomain.com serves HTTP-only or has a certificate error, adding includeSubDomains will break those subdomains for users whose browsers already received the HSTS policy. Audit all subdomains before enabling this directive.

Forgetting that preload is a long commitment. Removal from the preload list requires submitting a removal request and then waiting for the change to ship in browser releases. During that window, users whose browsers already have the preloaded entry can’t visit your site over HTTP even if you want them to. Treat preloading as permanent.

Setting max-age too short for non-preload HSTS. For ordinary (non-preloaded) HSTS, any max-age above zero works. But many security auditors and compliance tools flag values under 15768000 (six months) as weak. The one-year minimum for preloading is also a sensible floor for non-preloaded sites.

Tips and notes

Start with a short max-age (for example 86400, one day) while testing, then ramp to 31536000 once every subdomain is confirmed working. Only add preload at the end, once everything is stable.
includeSubDomains forces every subdomain to HTTPS; verify they all work first.
The base-domain HTTP response must redirect to its own HTTPS before anything else. Some hosts redirect www to non-www at the HTTP level, skipping the HTTPS step — that fails the requirement.
Without preload, the same header still enables ordinary dynamic HSTS, which protects all return visitors.