HSTS preload

What this check does

Looks up your domain in the Chromium HSTS preload list — a static list of HTTPS-only domains compiled directly into Chrome, Firefox, Safari, Edge, and Brave. For listed domains, browsers refuse plain-HTTP connections from the very first request, before any header has been seen.

The check returns one of: preloaded, pending submission, not preloaded, or removal in progress.

Why it matters

HSTS closes the downgrade-attack window — but only after a browser has seen the header once. The very first visit a user makes to your domain is still plaintext. On hostile Wi-Fi or with a compromised router, an attacker can intercept that first request, strip the redirect to HTTPS, and serve a malicious version of your site before HSTS ever kicks in.

Preloading eliminates the window. The browser knows your domain is HTTPS-only before the user types the URL. Even on a brand-new install with zero history, the first request is encrypted.

This matters most for: banking, healthcare, accounts with valuable credentials, payment flows, and any site where the first visit could compromise the user. For a marketing site with no auth, preload is a nice signal of operational maturity but not load-bearing.

The trade-off: preloading is hard to undo. Removal typically takes 6–12 weeks via the Chrome stable channel, and users on older browser versions stay locked-in even longer. Submit only when you’re certain your domain will speak HTTPS forever.

How to fix it

1. Verify the prerequisites before submission.

Per hstspreload.org policy, your site must:

• Serve a valid HTTPS certificate on the apex domain and www.
• Redirect HTTP → HTTPS on the same host (see redirect HTTP to HTTPS).
• Send an HSTS header on every HTTPS response with:
  • max-age ≥ 31536000 (one year)
  • includeSubDomains
  • preload
• Serve all subdomains over HTTPS too — includeSubDomains means it.

The production-ready header:

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

Two years is the conventional value once you’re confident.

2. Configure the header.

nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Cloudflare: SSL/TLS → Edge Certificates → HSTS → set max-age to 12+ months, enable Include subdomains, enable Preload, enable No-Sniff Header.

3. Verify before submitting.

curl -sI https://yourdomain.com | grep -i strict-transport-security
curl -sI https://www.yourdomain.com | grep -i strict-transport-security
curl -sI https://anysubdomain.yourdomain.com | grep -i strict-transport-security

All three should return the header with all three directives. If a subdomain is missing the header or serves non-HTTPS, submission will be rejected.

4. Submit at hstspreload.org.

Enter the domain at hstspreload.org, accept the warnings, click Submit. The form runs the same verification as the manual check above. Approved domains land in the next Chrome release (6–12 weeks to stable). Firefox, Safari, and Edge pull from the Chromium list with their own cadence.

5. Plan for the worst case before you submit.

Walk through these failure modes and confirm each is OK:

• Cert expires unattended. Users get a hard error with no HTTP fallback. Automate renewal (Let’s Encrypt + certbot timer or your cloud provider’s managed cert).
• Subdomain needs HTTP (legacy device, IoT, internal tool). Won’t work. You’re locked into HTTPS everywhere for the eTLD+1.
• Acquisition / domain sold. The new owner inherits the preload entry until removal completes. Buyers should check the preload list before purchase.
• Internal-only domain accidentally submitted. Removal takes months. Submit only public production domains.

6. Removal, if you ever need it.

Submit a removal request at hstspreload.org. The domain is taken off the next Chromium update (~6 weeks). Older browser installs stay locked for as long as their max-age says, and users who don’t update Chrome can be stuck for a year or more. Drop max-age to a small value (e.g. 300) well in advance to limit residual lock-in.

Frequently asked questions

Do I need preload if I already have HSTS?

For most marketing sites, no. Plain HSTS protects everyone after their first visit, which is good enough when there’s no auth or payment flow. Preload matters when (a) you handle credentials, money, or PHI, (b) you can guarantee HTTPS forever, and (c) you’ve already shipped HSTS for at least a few months without issues.

How long does it take to actually appear in Chrome?

Submission to first Chrome stable release: typically 6–12 weeks. The form will say “pending” until the next list compile, then “pending preload” while it ships through Chrome’s release channels (canary → dev → beta → stable). Firefox, Safari, and Edge pull from the Chromium list with their own update cycles — figure 3–6 months for broad coverage.

Can I preload a subdomain only, like app.example.com?

Yes, but only if the parent eTLD+1 isn’t already preloaded. Submit app.example.com directly. The same prerequisites apply (HSTS header with preload directive, HTTPS everywhere on that hostname). This is the right approach when you control one subdomain but can’t commit the whole organization to HTTPS-forever.