HSTS preload list — when submission is worth the lock-in

The HSTS preload list at hstspreload.org is a hardcoded set of hostnames that browsers refuse to load over HTTP, full stop. The list ships inside Chrome, Edge, Firefox, Safari, Opera, and Brave. Submission is a one-way door. Removal exists, but the path is slow and your users are stuck with cached enforcement long after you ask the Chrome team to delist. Most security writeups treat preload as the obvious win. The real answer: ship HSTS first, prove your subdomain coverage for six months, then submit.

What HSTS actually does without preload

RFC 6797 defined HTTP Strict Transport Security in November 2012. The mechanism is a single response header. A browser that receives it on an HTTPS response will refuse to downgrade to plaintext for the lifetime of max-age. The minimum useful value most operators ship:

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

max-age=31536000 is one year in seconds. includeSubDomains extends the policy to every host below your apex. There's a problem this header alone doesn't solve. The first request a fresh browser ever makes to your origin can still go over HTTP. An attacker on the network path can intercept that first hit and stop the HSTS header from ever arriving — the trust-on-first-use gap. Preload exists to close that gap by shipping the policy in the browser binary.

Preload eligibility, exactly

The hstspreload.org submission form runs an automated check before a human reviews anything. Your apex must serve HTTPS on port 443 with a valid certificate. HTTP on port 80 must redirect to the same host on HTTPS, not jump straight to a www. or apex flip. The HSTS header on the HTTPS response must include max-age of at least 31536000, the includeSubDomains directive, and the preload token. The preload-eligible header looks exactly like this:

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

Miss any of those and the form rejects the submission. The order of directives doesn't matter to the parser, but every one of them must be present on the response served from your apex over HTTPS. The Chromium HSTS preload documentation lays out the same rules with the same numbers.

Browsers that consume the list

Chrome ships and maintains the preload list as part of Chromium. Firefox ingests a periodically synced copy from the Chromium source tree, documented in Mozilla's Necko networking notes. Safari pulls from the Chromium list for WebKit on macOS and iOS. Microsoft Edge inherits the list from its Chromium base. Opera does the same for its Chromium-derived browser. Brave, also Chromium-based, ships the list with each release. One submission propagates to every mainstream desktop and mobile browser within a few release cycles — usually 12 to 18 weeks, depending on each vendor's release cadence.

The removal path is slow on purpose

Preloading is engineered to be hard to undo. The Chromium HSTS preload removal documentation describes the workflow: file a removal request through hstspreload.org, wait for Chrome team review, get accepted into the removal queue, then wait for that change to ship in a stable Chrome release. After the binary updates, every existing browser still has to receive the new build. Users on older Chrome installs continue to enforce the old policy. Realistically, expect months from request to broad effect, not days. Firefox, Safari, and Edge each pick up removals on their own schedules. Submitting under the assumption that you can roll back next quarter is wrong.

The subdomain gotcha that breaks sites

includeSubDomains is the directive that turns preload into a footgun. Once your apex is on the list, every hostname under it must work over HTTPS. Forever. Internal admin tools on admin.example.com, a legacy WordPress install on blog.example.com, a Jenkins UI on ci.example.com, a vendor portal on partner.example.com — anything reachable inside or outside your network — must serve a valid TLS certificate and accept HTTPS connections. If a subdomain has no certificate or terminates only on port 80, browsers will refuse to load it. There is no override on the user side. No "proceed anyway" button on a preloaded host.

This is the failure most operators don't model. Marketing sites get audited. Hidden subdomains under acquisitions, internal services that pre-date the TLS rollout, third-party SaaS pointing a CNAME at your DNS — those are the surfaces that break the day preload reaches a user's Chrome update. Audit DNS for every record under your apex. Hit each one over HTTPS. Confirm a valid certificate. Only then submit.

When not to submit

Skip preload if any subdomain serves traffic over HTTP only. Skip it if you operate split-horizon DNS where internal subdomains use private CAs the public web can't validate. Skip it if your organization uses the apex for short-lived experiments, vendor demos, or partner integrations that won't get TLS for cost or political reasons. Skip it if there's a real chance you'll move the apex domain — preload is bound to the hostname you submitted, and a domain pivot strands the old apex on the list with no easy way to redirect it.

The honest test: can you commit to HTTPS on every current and future subdomain under this apex for the next decade? If the answer is anything other than a flat yes, ship the year-long HSTS header without preload and move on. The TOFU gap matters less than a self-inflicted outage on intranet.example.com.

A realistic rollout sequence

Start with a short max-age and no includeSubDomains to prove the HTTPS baseline holds:

Strict-Transport-Security: max-age=300

Five minutes. Watch logs for HTTPS handshake errors and HTTP traffic patterns for a week. Step up to 86400 (one day), then 604800 (one week), then 2592000 (30 days). At each step, audit subdomain coverage again. Add includeSubDomains only after every host under the apex is confirmed HTTPS-only. Move to max-age=31536000; includeSubDomains and hold there for six months minimum. If nothing breaks in that window, the preload submission is finally a low-risk decision. The 18-week minimum max-age the preload list enforces exists for the same reason — it's the bake time the Chrome team wants you to commit to before they bake your hostname into the binary.

Verify before shipping

isitready.dev inspects your live HSTS header and reports whether the value meets the hstspreload.org eligibility rules — max-age length, includeSubDomains presence, the preload token, and the redirect chain on port 80. Run it against your apex before you click submit, and rerun it after every certificate or DNS change on a subdomain.