How to Remove HSTS Preload Once It’s Set

One of the most common questions about HSTS is: “What if I change my mind?”

Here’s the reality: preloading is meant to be permanent. Once your domain is in the global HSTS preload list, every major browser ships with the rule baked in. That means even if you drop HTTPS or remove the header on your server, browsers will keep forcing HTTPS until they’re told otherwise through an official update cycle.

So yes, you can request removal… but it’s slow, and it comes with caveats.

This guide is written in response to our guide on how to “enable” HSTS. Since it is such a sensitive thing to do, it’s best to be safe as opposed to being sorry later.

How the Removal Process Works

Assuming that you’ve made a mistake, this is what you need to do:

1. Undo the preload signals on your server
   First, clean up your header. You must:
   • Remove the preload directive.
   • Set max-age=0. This tells browsers you’re withdrawing the HSTS policy.
   Example: Strict-Transport-Security: max-age=0
2. Submit a removal request
   Go to hstspreload.org and enter your domain. The form will check whether your site is serving the correct removal header before it allows you to continue.
3. Wait for browser updates
   If the request is approved, the Chromium project removes your domain from the preload list. Other browsers (Firefox, Safari, Edge, Opera) eventually sync the change. But here’s the deal: removal doesn’t hit users instantly. It can take weeks or even months before enough people update their browsers to stop enforcing the preload rule.

Why It’s a Headache

This process is intentionally strict. The entire point of HSTS preload is to guarantee a domain will always load securely. If removal were fast and loose, attackers could abuse it. That’s why you should think of preloading as a one-way street—something you only commit to once every subdomain is locked down and HTTPS is here to stay.

Let’s make it concrete. Suppose you preload example.com with includeSubDomains, but you later decide to spin up mail.example.com without HTTPS. Everyone’s browsers will block it outright. Even if you fix your headers, you’re stuck waiting for the preload removal to propagate, which might take months. That’s real downtime and real frustration for users.

Before you ever consider preloading, follow a staged approach:

1. Phase 1 – Short max-age
   Start small with max-age=300 (five minutes). If something breaks, browsers forget quickly.
2. Phase 2 – Longer durations
   Once you’re confident, bump it to a week, then a month, then a year.
3. Phase 3 – Include subdomains
   Only after you’ve tested every subdomain should you add includeSubDomains.
4. Phase 4 – Preload
   When you’re absolutely sure, add preload and submit to hstspreload.org. At this point, you’ve closed the door behind you.

Preload is the nuclear option of HTTPS security. It’s excellent once you’re ready, but removal is cumbersome by design. If you treat it casually, you risk locking out legitimate traffic for months. Roll it out slowly, test obsessively, and only preload when you’re certain that HTTPS is permanent across your entire domain and subdomains.

In other words: measure twice, preload once.