What Is HSTS? A Plain-English Guide to Strict Transport Security

You're probably here because a header checker flagged something called HSTS on your site, or you spotted the term while reading about HTTPS and it wasn't clear whether the two were the same thing. So, what is HSTS? In short: it's an instruction your server sends to a visitor's browser, telling it to never load your site over an unencrypted connection again, not even by accident. That one sentence does a lot of work, so let's unpack it properly.

Picture someone connecting to the free Wi-Fi in a hotel lobby. They type your domain into the address bar without bothering to add "https://" (almost nobody does). Without HSTS in place, the browser's first move is a plain, unencrypted HTTP request. On a trusted network that's harmless, because your server immediately redirects to HTTPS.

On a hostile network, that first unencrypted request is exactly the window an attacker on the same Wi-Fi needs to intercept the traffic, rewrite the page, or steal a session cookie before the redirect even happens. HSTS closes that window by making the browser skip the insecure request entirely. It remembers your site and goes straight to HTTPS, every time, whether or not you typed the "s".

How Strict Transport Security Actually Protects Your Site

What HSTS stands for (and where it comes from)

HSTS stands for HTTP Strict Transport Security. It isn't a piece of software or a certificate type; it's a web security policy mechanism, delivered through a single response header, that tells a browser to treat a domain as HTTPS-only for a set period of time. The mechanism was formalized by the IETF in RFC 6797, published back in 2012, which is still the reference document that defines exactly how browsers are supposed to behave once they've seen the header. Every modern browser, Chrome, Firefox, Safari, Edge, implements it according to that spec.

What the Strict-Transport-Security header does on the wire

The mechanism itself lives in one HTTP response header: Strict-Transport-Security. Your server sends it alongside a normal HTTPS response, something like this:

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

The first time a browser sees that header over a valid HTTPS connection, it stores a note for your domain: "always use HTTPS here, no exceptions, for the next X seconds." From that point until the note expires, three things change. The browser rewrites any plain HTTP request to your domain into HTTPS before it even leaves the device. It refuses to load the site at all if the connection can't be secured.

And, this is the detail people miss most, it will not let the visitor click through a certificate warning to view your site anyway. Normally a browser shows a "this connection isn't private" page with a small link to proceed at your own risk. HSTS removes that link. There's no bypass button, by design.

One important catch, straight from MDN's documentation on the header: if your server ever sends this header over plain HTTP instead of HTTPS, browsers ignore it completely. It only counts coming from a secure connection. That's a deliberate safeguard against an attacker injecting the header from an insecure channel.

The three settings that decide how strict "strict" is

Three directives control the header's behavior, and securityheaders.tools grades all three because together they're worth 20 of the 100 points in our own report. Worth knowing what each one actually does before you set it.

• max-age: how many seconds the browser should remember this policy. MDN commonly recommends a minimum of six months (15,768,000 seconds), with two years (63,072,000 seconds) suggested for stronger protection. Per the 2025 HTTP Archive Web Almanac, the median max-age across sites that send the header is 365 days.
• includeSubDomains: extends the same HTTPS-only rule to every subdomain, not just the one that sent the header. Skip this and you leave a gap: cookies set on your main domain can potentially be manipulated through an insecure subdomain, which is exactly the kind of gap OWASP calls out in its HSTS Cheat Sheet.
• preload: a request to be added to a hardcoded list, baked into every major browser, so the HTTPS-only rule applies from a visitor's very first connection, before your server has ever sent them the header. Submissions are tracked at hstspreload.org, the official list used by Chrome, Firefox, Safari and Edge. We'll come back to why that's a bigger commitment than it sounds.

According to the same Web Almanac chapter, HSTS adoption reached 36% of mobile pages in 2025, up six percentage points from the year before. Of the sites that do send it, 96% include a valid max-age, about 40% add includeSubDomains, and only around 22% go as far as preload. That gap between "sends the header" and "goes all the way to preload" isn't laziness. It's caution, and it's justified.

HSTS is one piece of a bigger picture. If you want the full rundown of every header our checker grades, from Content-Security-Policy to Permissions-Policy, see our guide to what each security header does.

Is HSTS the same as HTTPS?

No, and this is the mix-up that sends most beginners looking for an answer in the first place. HTTPS is the encrypted connection itself, the padlock, the certificate, the actual scrambling of data between browser and server. HSTS is a rule about HTTPS, not HTTPS itself. Think of HTTPS as a locked door and HSTS as a note taped to that door reading "always use the lock, never prop it open, no exceptions."

You can absolutely run HTTPS without HSTS; most sites did for years, and plenty still do. What you can't do is run HSTS without HTTPS, because the header only takes effect when it arrives over a secure connection in the first place. HTTPS is the mechanism. HSTS is the enforcement layer sitting on top of it.

Why HSTS exists: the attack it's built to stop

The scenario at the top of this article, someone on hostile Wi-Fi typing a domain without "https://", describes what's known as an SSL-stripping or downgrade attack. Even when your server correctly redirects HTTP to HTTPS, that first request still goes out unencrypted, and an attacker positioned on the same network can intercept it before the redirect completes, then quietly serve the victim a fake HTTP version of your site while relaying a real HTTPS session to you in the background. The victim sees your content and has no visible reason to suspect anything.

Security researchers refer to the underlying weakness as a "trust on first use" gap: the first connection to any site is inherently unprotected until the browser has some reason to know better. HSTS closes that gap for every visit after the first one, and preload closes it for the very first visit too, since the browser already has the rule baked in before it ever talks to your server.

What are the risks of turning HSTS on?

This is the part most explainers skip, and it's the part that matters most if you're about to enable this header. HSTS is safe and genuinely useful for the overwhelming majority of sites, but it isn't a switch you flip without thinking. Three things can go wrong.

First, locked-out subdomains. If you turn on includeSubDomains and one of your subdomains doesn't have a valid HTTPS certificate, or worse, is not meant to run over HTTPS at all, it becomes unreachable. This is the most common real-world incident pattern: a staging server, an old marketing microsite, or an internal tool that "isn't customer-facing" gets forgotten, and once includeSubDomains goes live it simply stops loading in any browser that remembers the policy.

Second, the long-memory problem. Once a browser stores your max-age policy, it holds onto it for the full duration you specified, regardless of what you do to your server in the meantime. Set max-age to two years and change your mind next month? Visitors who already loaded your site keep enforcing HTTPS-only for up to two years, whether your certificate is still valid or not.

Third, and the sharpest warning in the source material, preload is close to irreversible. OWASP's cheat sheet states plainly that submitting your domain to the preload list "can have PERMANENT CONSEQUENCES and prevent users from accessing your site and any of its subdomains if you find you need to switch back to HTTP." Removal from the preload list, once you're on it, takes months and depends on the next browser release cycle, not on anything you control directly.

There's also a quieter privacy wrinkle worth a mention: because HSTS state persists in the browser, it can theoretically be used as a weak fingerprinting signal to help identify a returning visitor without cookies, something OWASP flags as a known, if minor, side effect of the mechanism.

None of this means avoid HSTS. It means roll it out the way OWASP itself recommends: start with a short test value, something like max-age=86400; includeSubDomains (24 hours), confirm every subdomain genuinely works over HTTPS, then extend the max-age gradually before you ever consider preload.

Checking whether your site already sends it

If you got here because you're not sure whether your site sends this header at all, or whether the value it sends is actually strict enough to matter, that's a two-minute check rather than a guessing game. Run your domain through the securityheaders.tools checker and it'll fetch your live headers, tell you whether HSTS is present, missing, or misconfigured, and show you exactly which points you're losing and why. It's the same grading logic referenced above: max-age, includeSubDomains, and preload each get evaluated on their own.

Adding the header without locking yourself out

If the checker comes back showing HSTS missing or weak, the safest path is to build the header value deliberately rather than copy a "production-ready" line from a blog post. The securityheaders.tools generator walks through the max-age, includeSubDomains, and preload options one at a time and flags conflicting combinations, like preload without a year-long max-age, before you ever paste anything into your config.

If your stack runs on Apache, htaccess.tools has the specific rule syntax for writing the header into your .htaccess file once you know the value you want. Either way, treat the rollout order from the risk section above as non-negotiable: short test value first, full subdomain coverage confirmed second, preload only once you're certain you'll never need to step back.

Frequently Asked Questions

What does HSTS stand for?

HSTS stands for HTTP Strict Transport Security. It's the name of a web security policy mechanism defined in RFC 6797, delivered through the Strict-Transport-Security response header, that forces browsers to only ever connect to a site over HTTPS for a set period of time.

What does the Strict-Transport-Security header do?

Once a browser receives this header over a valid HTTPS connection, it remembers the policy and automatically rewrites any future plain HTTP request to that domain into HTTPS, refuses the connection if HTTPS isn't available, and blocks visitors from clicking through certificate warnings to view the site anyway. It only takes effect when sent over HTTPS; browsers ignore it entirely if it arrives over plain HTTP.

Is HSTS the same as HTTPS?

No. HTTPS is the encrypted connection itself, the padlock and certificate that scramble traffic between browser and server. HSTS is a rule sitting on top of HTTPS that tells the browser to always use that encrypted connection and never quietly fall back to an unencrypted one. You can have HTTPS without HSTS, but HSTS depends entirely on HTTPS already being in place.

What are the risks of enabling HSTS?

The main risks are locking out subdomains that don't have valid HTTPS certificates when includeSubDomains is enabled, being stuck with a policy that browsers keep enforcing for the full max-age duration even after you change your server setup, and, most seriously, submitting your domain to the browser preload list before you're certain you'll never need plain HTTP again, since removal from that list can take months. Starting with a short test max-age and extending it gradually, as OWASP recommends, avoids most of these problems.