HSTS preload is a one-way street: what removal actually takes

Submitting a domain to the HSTS preload list is a one-way door in practice, not in theory. The theory says you can request removal any time. The practice is that the official removal page states removal "may take 6-12 weeks to reach most Chrome users, and may take longer for other browsers." Most third-party guides say "months" without the specifics, which hides exactly the part that matters: which browser, and why the wait exists at all.

Why 6-12 weeks, specifically

The number is not arbitrary. Chromium's own preload-list documentation states the list "should be updated with entries from the pending API at least once per Chromium release." Chrome ships a new stable release roughly every four weeks. A removal request has to be processed, merged into an upcoming build, and then reach users as that build rolls out, which is where the 6-12 week range comes from: one to three release cycles, not a single flag flip.

That range is also a best case. It assumes the removal request is processed promptly, meaning it clears the maintainers' review and gets merged into the next available release rather than slipping to a later one because it arrived close to a release cutoff. It describes reaching "most" Chrome users, not all of them, since a rolling release does not update every installed browser at once, even after a build ships, adoption climbs gradually as auto-update runs on each user's machine. Anyone still on an old, unpatched Chrome build keeps enforcing the stale policy until they update, which the preload maintainers have no way to force.

Chrome is not the whole story

Firefox and Safari do not read Chromium's live list in real time. Both browsers bundle their own snapshot of the preload list, pulled from the same public source data but shipped on their own release schedule, independent of Chrome's. A removal reaching most Chrome users in 6-12 weeks says nothing about when the same removal reaches Firefox or Safari users, since each browser vendor decides independently when to refresh its own bundled snapshot. Testing a removal in Chrome and assuming it applies everywhere is a real way to get this wrong.

The requirement most people miss before requesting removal

Removal from the list does not require dropping HSTS entirely, only the preload directive itself. The site still needs to keep serving valid HTTPS with a valid HSTS header, one that omits preload, to be eligible. Sending no HSTS header at all, or an invalid one, does not speed anything up, it leaves the site non-compliant with the removal criteria while the existing preload enforcement is still active in already-updated browsers.

This is also why testing without the preload directive before formally requesting removal is worth doing deliberately, not skipping. Dropping the directive from the live header first shows whether anything in the current setup was quietly depending on preload-level enforcement, before the slow removal clock even starts, and it is the same header state the official removal criteria actually require to be met anyway.

The submission side, briefly

Getting onto the list has its own well-documented checklist elsewhere, so this is the short version: every subdomain under the domain, not just the apex, has to serve valid HTTPS before submitting, because includeSubDomains applies to the whole tree, an internal admin panel, a staging environment, or a forgotten legacy subdomain included. A certificate expiring on any one of them locks users out until it renews. The header on the base domain needs max-age=31536000 (one year) at minimum, the includeSubDomains directive, and the preload directive itself, all present together, plus a same-host redirect from HTTP to HTTPS.

The subdomain audit is the step most likely to be skipped under time pressure, and the one that causes real lockouts later. A full inventory means checking every DNS record under the domain, not just the ones actively linked from the main site, since includeSubDomains does not care whether a subdomain is documented or forgotten, only whether a resolver can find it.

Before requesting removal, or before submitting in the first place

• Confirm every subdomain actually needs to be covered: a subdomain that cannot serve HTTPS today, an internal tool, a legacy system, is the most common reason teams later regret submitting
• Test with the HSTS header live but without preload first: catches real breakage while there is still a fast way out, before the slow removal clock starts
• Plan for the 6-12 week Chrome figure as a floor, not a ceiling: a delayed processing step or a skipped release cycle pushes it past that range
• Do not assume Chrome behavior applies to Firefox or Safari: each ships its own snapshot on its own schedule, verify separately if cross-browser timing actually matters for the situation
• Keep serving valid HTTPS with HSTS present, without preload, during the removal window: this is a stated eligibility requirement, not optional