HSTS Preload Explained: How Browsers Force HTTPS From the Very First Visit

Type example.com into your browser. You didn't type https://, so the browser sends an HTTP request first. The server responds with a 301 redirect to https://example.com, the browser follows it, and from that point on everything is encrypted. By any reasonable definition, you're now on a secure connection.

Except that very first request — the plaintext one, the one before the redirect — went out across the network unprotected. Anyone sitting between you and the server saw it. And anyone sitting in that position can do something far worse than read it: they can answer it, pretending to be the server, and never send the redirect at all.

That attack is called SSL stripping, and the defence against it is a header called Strict-Transport-Security — better known as HSTS. The header works after the first visit. Closing the first-visit gap requires something extra: getting your domain onto the HSTS preload list baked into every browser. This post explains how both pieces work, the requirements for preloading, and the very real reasons to think twice before opting in.

The problem HSTS solves

SSL stripping was popularised by Moxie Marlinspike's sslstrip tool in 2009, and the mechanics haven't really changed. The attacker sits on the same network as the victim — coffee-shop Wi-Fi, a hotel network, a compromised router. The victim types bank.com into the address bar. The browser sends an HTTP request. The attacker intercepts it, opens a real HTTPS connection to bank.com on the victim's behalf, and proxies the traffic. From the victim's side, everything looks normal except for the missing padlock — which most people don't notice. The attacker sees every password, every cookie, every form field.

The naive defence is "just type https://." Nobody does. The slightly better defence is the HTTP → HTTPS redirect, which every modern site has. But the redirect happens after the first plaintext request — too late.

HSTS reframes the problem. Instead of relying on each visit to redirect itself, the server tells the browser, once: never use HTTP for this domain again. The browser remembers, and from then on every navigation, every fetch, every subresource goes straight to HTTPS — even if the user types http://, even if a link is wrong, even if a redirect would have done the wrong thing. The plaintext request never leaves the machine.

How the Strict-Transport-Security header works

HSTS is delivered as a response header on any HTTPS response. A typical example:

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

Three directives, each doing one specific job.

max-age — How many seconds the browser should remember the rule. 31536000 is one year; 63072000 is two. Each time the browser sees a fresh HSTS header, it resets the clock. If you ever need to turn HSTS off, you set max-age=0 and wait for every visitor's TTL to expire — a long process, which is part of what makes HSTS feel permanent.

includeSubDomains — Apply the rule to every subdomain, not just the exact hostname that sent the header. A response from example.com with this directive locks down www.example.com, api.example.com, blog.example.com, and anything else under example.com, forever (or until max-age elapses). This is powerful — and dangerous if you have subdomains that aren't ready.

preload — A signal that you want this domain added to the browser's preload list. It does nothing on its own; it's a flag the preload-list maintainers check before accepting a submission. We'll come to that.

When a browser sees the header for the first time, it stores the directive against the hostname. Every subsequent request to that hostname — and, if includeSubDomains is set, every request to any subdomain — is silently upgraded from http:// to https:// before the request even leaves the browser. The 301 redirect step disappears entirely. If the certificate is invalid, the browser refuses the connection with no clickthrough option; the user cannot bypass an HSTS-protected error page the way they can a normal certificate warning. HSTS hardens HTTPS in both directions: it forces the upgrade and it removes the escape hatch.

The header is part of the standard set of HTTP security responses; we cover the others in HTTP security headers explained, and you can inspect what any site is sending today with our HTTP header inspector.

What preloading adds

The HSTS header has a glaring weakness: the browser has to see the header at least once before the rule takes effect. The very first request — the SSL-strippable one — is exactly the request HSTS can't protect, because the header that would have protected it is in the response to that request.

Preloading closes that gap by skipping the server entirely. The HSTS preload list is a hardcoded list of domains shipped inside every major browser. Chrome maintains the canonical list at hstspreload.org; Firefox, Safari, Edge, Brave, and Opera all consume it (or maintain near-identical copies of their own). When a preloaded domain appears in your browser's address bar, the browser knows — before sending any request, before doing DNS, before opening a TCP connection — that this domain is HTTPS only. The plaintext request never happens, even on the very first visit from a fresh install.

Submission is straightforward in principle: visit hstspreload.org, enter your domain, and the form runs a series of checks against your live server. If you pass, you click submit and your domain is queued. From there it ships in the next Chromium release (typically 6–12 weeks), and other browsers pick it up shortly after. There's no fee, no account, and no review beyond the automated checks. Removal, on the other hand, takes months — which is the single most important sentence in this post.

The four preload requirements

The submission form will reject you if your domain doesn't meet four conditions. Each one exists for a specific reason.

1. A valid HTTPS certificate. Self-signed, expired, mismatched, or untrusted certificates fail. Once you're preloaded, the browser will refuse to connect over anything else, so a broken certificate means the site is unreachable. Check your certificate chain with our SSL/TLS inspector, and verify it's properly logged by the public Certificate Transparency logs while you're at it.

2. A working HTTP → HTTPS redirect on the apex. Even after preloading, you need the redirect for clients that don't honour the preload list (older browsers, scripts, command-line tools). The redirect must be to the same hostname over HTTPS first — not directly to a different domain — and it must be a 301 or 308.

3. max-age of at least one year. The exact threshold is 31536000 seconds. The reasoning: preload-list inclusion is effectively permanent for any client that has the list, so the dynamic header has to commit to at least the same horizon. Shorter values are accepted in the header but rejected by the preload submission form.

4. includeSubDomains and preload directives present. Both must be in the header. includeSubDomains is required because the preload list works at the apex domain level — if you submit example.com, Chrome enforces HTTPS for every subdomain of example.com whether you wanted that or not. The directive on your live response just makes that explicit. preload is the signal that you've read the documentation and you understand what you're opting into.

Risks and caveats

Preloading is not a configuration change. It's a one-way commitment that propagates into millions of browser binaries and stays there for the lifetime of every install. The risks are real and worth spelling out.

Removal takes months. If you submit a domain and then change your mind, you can request removal — but the change only ships in the next Chrome release, and even then it doesn't reach users until they update. Older Chrome versions stuck on a pinned release continue to enforce HSTS for that domain potentially forever. Plan as if preloading is permanent.

includeSubDomains covers every subdomain. If you preload example.com and a year later you stand up legacy-thing.example.com on a host that doesn't have a valid TLS certificate, it will be completely unreachable from any browser that has the preload entry. Internal dashboards, dev environments, marketing microsites on shared hosts, third-party SaaS subdomains pointed at CNAMEs — anything under your apex that isn't HTTPS-ready is now broken, with no warning click-through.

Wildcards are not subdomain-aware. A wildcard *.example.com certificate doesn't cover deeper hostnames like foo.bar.example.com. If you have multi-level subdomains, you need a more careful certificate strategy before preloading. Tightening your CAA records before submission is also worth doing — it limits which certificate authorities can issue for your name, reducing the blast radius of a mis-issuance.

You can't carve out exceptions. There is no "preload example.com except for dev.example.com" option. The model is all-or-nothing per apex.

The conservative path is the standard one: deploy the header with a short max-age first (a week, then a month), confirm nothing breaks, raise to a year, add includeSubDomains only when every subdomain is verified HTTPS-clean, and only then add the preload flag and submit. Skipping these stages because the submission form will accept you anyway is how organisations end up locked out of their own internal tools.

HSTS in practice

The preload list now contains over 150,000 domains, and most of the names you'd expect are on it. Google's properties (google.com, youtube.com, gmail.com), Facebook and its family, Twitter/X, GitHub, Stripe, every major bank, most government services. .dev and .app are preloaded at the TLD level — every domain ending in those suffixes is HTTPS-only in every browser, with no per-domain submission needed.

You can check whether any domain is on the list by querying hstspreload.org directly, or by using our HSTS preload checker, which also breaks down the live header your server is sending and flags whether it meets each of the four preload requirements.

HSTS is one of several signals that, together, make HTTPS hard to attack. Certificate Transparency logs make it impossible to issue a certificate for your domain without it being publicly visible. CAA records let you restrict which authorities are allowed to issue at all. And the broader set of security headers — CSP, X-Frame-Options, Referrer-Policy — protects what happens once a connection is established. HSTS is the piece that makes sure the connection itself is honest.

Treated carelessly, it's a footgun. Treated as the long-term commitment it actually is, it's the single most effective deployment-time mitigation against active network attackers — and the only one that protects the very first visit.