Test if your site enforces HTTP Strict Transport Security

What is HSTS and why an HSTS checker matters

HTTP Strict Transport Security, usually shortened to HSTS, is a response header that tells a browser to stop asking politely and start refusing plain HTTP entirely. Once a browser has seen the Strict-Transport-Security header for a domain, every future request to that domain — even one typed as http:// — is rewritten to https:// before it ever leaves the device. That single behavior closes one of the most exploited gaps in web security: the brief, unencrypted first request that happens before a redirect has a chance to run.

Without an HSTS header, a site is still vulnerable during that opening moment. An attacker positioned on the same network — a coffee shop hotspot, a compromised router, a rogue access point — can intercept the initial HTTP request and quietly strip or rewrite the redirect to HTTPS, keeping the victim on plain HTTP while presenting a convincing copy of the real site. This class of attack, commonly called SSL stripping, is exactly what HSTS is designed to prevent, because the browser never sends that first vulnerable request in the first place once the policy is cached.

Running an HSTS checker is the fastest way to confirm the header meaning is actually in effect, rather than assumed. A useful HSTS tester does more than confirm the header exists — it verifies the max-age directive is long enough to matter, checks whether includeSubDomains is present so a forgotten subdomain can't become the weak link, and looks at whether the domain qualifies for and has joined the browser preload list. Each of those pieces changes the real-world protection level, and a header with a max-age of a few seconds provides almost no benefit compared with the one-year minimum browsers expect from a serious policy.

A typical HSTS header looks like this in practice: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. The max-age value is a duration in seconds — 63072000 equals roughly two years — during which the browser will automatically enforce HTTPS for that host without asking the server again. includeSubDomains extends that same enforcement to every subdomain, and preload signals that the site owner intends to submit the domain to the hardcoded preload list shipped inside Chrome, Firefox, Safari and Edge, removing the trust-on-first-use gap completely.

Configuring the header is usually a short server change. On Apache, adding Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" inside the HTTPS virtual host is enough, provided mod_headers is enabled. On Nginx, the equivalent is add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; placed inside the relevant server block. Many CDNs and reverse proxies, including Cloudflare and most managed hosting panels, also expose a toggle for this under their edge or security settings, which can be faster to enable than editing server configuration directly.

Before turning on includeSubDomains or requesting preload status, it's worth confirming every subdomain actually serves valid HTTPS, since the policy applies unconditionally once cached — a subdomain still running plain HTTP would become unreachable in supporting browsers. This HSTS tester exists to make that verification fast: run a single check before a launch, or run the bulk website test across an entire domain portfolio before rolling the header out everywhere at once, and get a live, header-by-header answer instead of guessing.