HSTS, or HTTP Strict Transport Security, is a response header defined in RFC 6797 that tells a browser to communicate with your domain over HTTPS only for a set duration. Once a browser has seen a valid Strict-Transport-Security header, it rewrites every future http:// request to https:// internally, before any packet leaves the machine, and refuses to let users click through certificate warnings for that host. This closes the gap where the very first request to a site can travel over plaintext and be intercepted — a technique called SSL-stripping. The protection lasts for the number of seconds given in the max-age directive, and the timer resets each time the browser sees the header again, so active visitors stay continuously protected.

What is the HSTS preload list and should I join it?

The preload list is a set of domains hardcoded into browsers like Chrome, Firefox, Safari and Edge. For a listed domain, the browser enforces HTTPS-only from the moment it is installed, before it has ever contacted your site — closing the one gap plain HSTS cannot, the genuine first visit. You should join it only after you are certain every subdomain you own serves valid HTTPS, because the required includeSubDomains directive applies to all of them. Joining is a strong, long-term commitment: submit at hstspreload.org with max-age of at least one year, includeSubDomains, and preload set, and an HTTP-to-HTTPS redirect in place. If you still have HTTP-only subdomains, wait.

What max-age should I use for HSTS?

For the preload list, max-age must be at least one year, which is 31536000 seconds. A common production value is two years, or 63072000 seconds, which is what the preload tooling recommends. However, you should not start there. When first rolling out HSTS, set a short max-age — a few minutes — so that if something breaks, browsers forget the policy quickly. Confirm every subdomain still loads, then raise the value in stages. Only once you have run at the full long duration without problems should you add the preload directive and submit. The long max-age is the goal, but reaching it gradually protects you from locking visitors out of a misconfigured host you cannot quickly fix.

How do I remove my domain from HSTS preload?

Removal is requested through hstspreload.org, but it is slow — measured in months, not hours. After your request is processed, the change has to ship in a browser release and then propagate to users as they update, and many people update infrequently. In the meantime, browsers that already cached the preloaded policy continue to enforce HTTPS-only on your domain and its subdomains. There is no fast rollback. This is exactly why you should test thoroughly with a short max-age before adding the preload directive: once a domain is on the list, you are committed for a long time. Verify every subdomain serves HTTPS first, and treat preload submission as a decision you cannot easily reverse.

HSTS and the Preload List: A Complete Guide

HTTP Strict Transport Security (HSTS) is one of the simplest security headers to send and one of the most consequential to get wrong. It tells a browser, in a single line, to communicate with your domain over HTTPS only — for a duration you choose — and to refuse any fallback to plain HTTP. Defined in RFC 6797, HSTS closes a small but real gap that exists even on sites that already redirect everything to HTTPS. This guide explains what the header does, how each directive works, what the browser preload list requires, and why you should commit to it carefully.

For the site owner (plain English)

In plain terms: HSTS is a one-line instruction that tells browsers to only ever reach your site over the secure HTTPS connection, never plain HTTP. It closes a small gap that exists even if you already redirect visitors to HTTPS. Most managed hosts, CDNs (such as Cloudflare), and website platforms let you switch it on without touching code. One caution is worth knowing first: the optional preload step is a long-term, hard-to-reverse commitment — every subdomain must serve HTTPS before you opt in — so start with a short duration and only add preload once you are sure everything works. If you are not certain whether your site already sends HSTS, the security headers checker will tell you in seconds.

What does HSTS do?

Most sites that use HTTPS still listen on port 80 and issue a redirect to the HTTPS version. That redirect is helpful, but it means the very first request a visitor makes can travel over unencrypted HTTP.

If someone types example.com into the address bar, the browser often tries http://example.com first, receives a redirect, and only then upgrades to https://. During that brief plaintext moment, an attacker positioned on the network — on shared Wi-Fi, for instance — can intercept the request and serve a malicious response before the redirect ever happens. This technique is commonly called SSL-stripping.

HSTS removes that window. Once a browser has seen a valid Strict-Transport-Security header from your domain, it remembers the instruction for the lifetime specified in max-age and rewrites every future http:// request to https:// internally, before any packet leaves the machine. There is no plaintext request to intercept and no redirect to tamper with. The browser also refuses to let users click through TLS certificate warnings for an HSTS-protected host, which turns a soft warning into a hard stop.

The one limitation is bootstrapping: the protection only applies after the browser has seen the header at least once. The first visit a brand-new browser ever makes to your domain is still unprotected. The preload list, covered below, exists precisely to close that remaining gap.

The header

A complete, preload-ready header looks like this:

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

It has one required directive and two optional ones. Each does something distinct.

max-age

The number of seconds the browser should remember to use HTTPS for this host. The value 63072000 is two years. The timer resets every time the browser sees the header again, so an active visitor effectively stays protected continuously. This directive is mandatory; a header without it is ignored.

includeSubDomains

Extends the policy to every subdomain of the host that served the header. A header sent from example.com with this directive applies to www.example.com, api.example.com, blog.example.com and every other subdomain — including ones that do not yet exist. This is powerful and also where most people get hurt, as discussed under risks below.

preload

A signal that you consent to having your domain baked directly into browsers' built-in HSTS lists. The directive itself does nothing in the browser; it is a marker the preload list maintainers check before accepting a submission. You add it, then submit your domain separately at hstspreload.org.

What is the preload list?

The HSTS preload list is a hardcoded set of domains shipped inside the browser itself. For any domain on the list, the browser treats it as HTTPS-only from the moment of installation — before it has ever made a single request to your site. This is the only mechanism that protects the genuinely first visit. The list is maintained by the Chromium project and consumed by Chrome, Firefox, Safari, Edge and other major browsers, so a single submission propagates broadly.

To be accepted at hstspreload.org, your domain must meet a specific set of requirements:

Serve a valid certificate on the domain.
Redirect all HTTP traffic to HTTPS on the same host (a plain http:// request must end up at the corresponding https:// URL).
Serve the HSTS header on the HTTPS site with a max-age of at least one year (31536000 seconds).
Include the includeSubDomains directive.
Include the preload directive.

Once submitted and accepted, your domain is added in a future browser release. Inclusion is not instant — it ships with a browser update and then reaches users as they update — and, crucially, neither is removal.

What are the risks, and can I undo it?

HSTS is durable by design, and that durability cuts both ways. The commitment you are making is not easily reversible, so two failure modes deserve careful thought before you submit.

The first is includeSubDomains. This directive applies to every subdomain, present and future. If any subdomain — a legacy admin panel, an internal tool, a partner integration, a development host — is still served over plain HTTP, browsers that have seen your policy will refuse to connect to it at all. There is no warning page to click through. The subdomain simply becomes unreachable for those users until it serves valid HTTPS.

The second is removal. Taking a domain off the preload list is a slow process measured in months. You request removal, it is processed, and then the change has to ship in a browser release and propagate to users as they update — and many users update infrequently. There is no fast rollback. If you preload a domain and later discover a subdomain you forgot about, you cannot simply undo the decision the way you would revert a configuration change. You commit, and you live with it for a long time.

Common gotcha: adding preload together with includeSubDomains before every subdomain serves HTTPS will lock visitors out of the HTTP-only ones — and you cannot quickly undo it, because removal from the preload list propagates over months, not hours. Test with includeSubDomains and a short max-age first (a few minutes), confirm that every subdomain you own still loads, raise the max-age gradually, and only then add preload and submit.

How do I verify my configuration?

After deploying HSTS, confirm the header is actually being sent on HTTPS responses. From the command line:

curl -sI https://example.com | grep -i strict-transport-security

You should see your full directive string in the response. Check that the max-age matches what you intended, that includeSubDomains appears only if you have verified every subdomain, and that a plain http:// request redirects to https://.

Before submitting to the preload list, run your domain through the checker at hstspreload.org, which validates every requirement and tells you exactly what is missing. Re-run these checks after any infrastructure change that could affect how headers or redirects are served.

Scan your site to see whether Strict-Transport-Security is present, how long its max-age is, and whether includeSubDomains and preload are set correctly.

Check your security headers →

Next steps

HSTS is one piece of a broader response-header posture. For the full set of recommended headers and how they fit together, see the pillar guide on security headers. To keep going on a closely related header that governs what content the browser is allowed to load, read our guide to the Content Security Policy.