Sudory
←Blog

One Google form decides how every browser treats your website.

Aleksej DixBy Aleksej Dix··6 min read

TL;DR. There is one HSTS preload list submission form on the public web: hstspreload.org, run by the Chrome team. According to that page itself, other major browsers (Firefox, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. Submitting your domain there is, in practice, the only path into every major browser. The catch hstspreload.org also flags up front: removal takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.

The story starts with a question. We were preparing to submit sudory.com for HSTS preload, which led us to hstspreload.org, a service run by the Chrome team. The natural follow-up: where is the Firefox form? Where is Safari's? Where is Edge's?

There aren't any. The hstspreload.org homepage states the situation directly: other major browsers maintain HSTS preload lists based on the Chrome list. There is no separate submission flow for Mozilla or Apple. The Chromium-based browsers (Edge, Brave, Opera, Vivaldi) inherit the Chrome list because they ship the same upstream code. That is the whole story.

Where the list actually lives

The source of truth is a single file in the Chromium repository: net/http/transport_security_state_static.json. When you submit your domain to hstspreload.org and pass the validation, the Chrome team eventually adds your entry to that file.

The downstream story differs by browser, and only Chromium and Firefox are open enough for outsiders to point at exact files:

  • Firefox generates its preload list from the Chromium file using a script in the Mozilla source tree at security/manager/tools/getHSTSPreloadList.js. The output gets checked in as security/manager/ssl/nsSTSPreloadList.inc. The script runs on Mozilla's release schedule, not Google's, so there is a delay of weeks to months before a new Chromium entry shows up in Firefox.
  • Safari ships an HSTS preload list based on the Chrome list per hstspreload.org's own description. Apple does not run a public submission flow. The exact location of the list inside WebKit and any Apple-side curation is not publicly documented, so we will not pretend to know more than that.
  • Edge, Brave, Opera, Vivaldi are Chromium-based and ship Chromium's preload file as part of the upstream code. They pick up updates whenever they pull a new Chromium build.
  • Tor Browser is built on Firefox ESR, so it inherits whatever HSTS preload list Mozilla ships in its ESR cut.

The practical result: one submission propagates to roughly every major browser within months. Chrome users see the change within a Chrome release. Firefox users wait for the next preload-list refresh in mozilla-central, which historically lands every few weeks but ships to most users on the slower ESR cycle. Safari and the Chromium-based browsers follow their own update cadences.

Why this is the way it is

It feels strange that one company maintains a list every browser depends on. The practical reasons are not mysterious.

The criteria for inclusion are technical and mechanical: serve HTTPS on the apex and www, redirect HTTP, send the right header. There is no editorial judgment to disagree with, so re-running the same check from a different vendor would produce the same answer.

The Chrome team also runs the validation infrastructure. Submitting to hstspreload.org triggers a live probe of your domain. The submission is rejected unless every check passes. The probe code is open source: it lives at github.com/chromium/hstspreload, the same library that backs the website at github.com/chromium/hstspreload.org. Anyone who wanted to verify a submission independently could run the same code; nothing about the curation step is closed.

The alternative is worse. If every browser took its own submissions, you would need to submit to four or five forms, each with its own edge cases, and your protection would land piecemeal across browsers. One submission flow with one set of rules is more useful in practice.

The four rules to get on the list

You cannot just send the HSTS header and walk away. The Chromium scanner checks all of the following before it accepts your submission:

  1. Serve a valid HTTPS certificate on both the apex domain (example.com) and the www subdomain. Self-signed certs are rejected. Expired certs are rejected.
  2. Redirect HTTP to HTTPS on the same host. The redirect must land on the HTTPS version of the same hostname, not on a different domain.
  3. Send the HSTS header on every HTTPS response with three required pieces:
    • max-age of at least 31536000 seconds (one year)
    • the includeSubDomains directive
    • the preload directive
  4. Submit at hstspreload.org and pass the live scan. The scanner re-runs the checks above and tells you exactly what to fix if anything is wrong.

If all four pass, your domain lands in the Chromium file within a few weeks and starts propagating to the other browsers from there.

The HSTS Academy entry walks through the header itself, the rollout from a short max-age to a full year, and the common mistakes that get submissions rejected.

The trap: getting off the list is hard

This is the part nobody warns you about. Submitting your domain to the preload list is a one-way decision in practice, even though removal is technically supported.

Here is what hstspreload.org itself says about removal: Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers. The Chrome team drops your entry from the next snapshot of transport_security_state_static.json; that ships in a future Chrome release; downstream browsers pick up the change on their own schedules. The first step is the only one with a stated timeline. Everything after Chrome is on someone else's calendar.

During the entire propagation period, every user whose browser still holds the old list will refuse to load your site over HTTP and will refuse to accept any HTTPS connection that does not match the rules. If you let your cert expire, if you accidentally serve a subdomain over HTTP, if you switch to a CDN that does not support HTTPS on a particular path, your users see a hard error with no override.

The HSTS preload list is not a switch you can flip. It is a one-way door. Walk through it only after you are certain every host under your domain can serve HTTPS today and will continue to serve HTTPS for years.

What this means for you

Two practical takeaways.

First, if you are submitting your domain, do it once and do it carefully. Read the four rules. Run the live scanner before you click submit. Make sure every subdomain you currently use, and every subdomain you might use in the next two years, can serve HTTPS. The HSTS Academy entry covers the rollout in detail.

Second, if your domain is already on the preload list, treat it like any other long-lived dependency. Cert expiry is now a hard outage, not a degraded warning. A new subdomain that misses HTTPS configuration is a hard outage. Sudory scans your domain for these regressions on a weekly schedule and emails you the moment one of them slips. That is what we built.

If you want to see your own domain's HSTS posture today, run the scan. The report will tell you whether you are eligible for preload, whether you are already on the list, and whether anything in your current setup would block re-entry if you ever needed to take your domain off and put it back on.

Sources

FAQ

Is there a separate HSTS preload list for Firefox?

No. Firefox builds its preload list by pulling Chromium's transport_security_state_static.json and converting it. The conversion runs on Mozilla's schedule, not Google's, but the source of truth is the Chromium file.

Does Safari have its own HSTS preload submission form?

No. Apple maintains a derived copy of the Chromium list inside WebKit. They curate which entries land in Safari, but they do not accept independent submissions. To get on Safari's list you submit to Chromium and wait.

How long does it take to get into every browser?

Chrome: weeks. Firefox: usually a few months, depending on the next ESR cycle. Safari: similar, depending on the next iOS or macOS release. Tor Browser: tied to Firefox ESR. So a single submission propagates across the web in roughly three to six months.

Can I remove my domain from the HSTS preload list?

Yes, but slowly. You file a removal request, Chromium drops you from the next list snapshot, and then every downstream browser picks up the change on their own cadence. The full removal takes months in Chrome and longer in Firefox and Safari. Plan your preload submission as a one-way decision.

What are the four rules to get on the HSTS preload list?

Serve a valid HTTPS certificate on the apex domain and on www. Redirect HTTP to HTTPS on the same hostname. Send the HSTS header on every HTTPS response with max-age of at least 31536000 seconds (one year), the includeSubDomains directive, and the preload directive. Submit at hstspreload.org and wait.

Aleksej Dix
Aleksej DixFounder of Sudory

Founder of Sudory. Frontend engineer based in Zurich with 20+ years shipping production web apps; now building continuous compliance scanning and writing about the DNS and email-auth controls behind it. Co-founder of WebZurich.