HSTS Checker

Check whether a site enforces HTTPS with HSTS. Enter a URL and this tool reads the live Strict-Transport-Security header and parses its policy: the max-age (and how long that is in plain English), whether includeSubDomains is set, and whether the domain is marked for preload. It is the fast way to confirm a site cannot be silently downgraded to http.

How to use the HSTS Checker

Enter a URL and press Check HSTS. The tool fetches the page and reports:

• Whether HSTS is enabled at all — that is, whether a Strict-Transport-Security header is present.
• The max-age in seconds and as a human duration (for example 31536000 seconds = 1 year).
• Whether includeSubDomains and preload are set, and the exact raw header value.
• A note if the policy is weaker than the threshold needed for preload eligibility.

HSTS only applies to HTTPS responses, so check the https:// version of the site. A site can be perfectly secure over HTTPS yet still lack HSTS, which is exactly what this catches.

What HSTS is and why it matters

HSTS (HTTP Strict Transport Security) is a response header that tells the browser: "for the next max-age seconds, only ever connect to this site over HTTPS, and never let the user click through a certificate warning". Once a browser has seen it, it upgrades every request to HTTPS automatically and refuses an insecure connection outright.

This closes a real gap. Without HSTS, the very first request a user makes — typing example.com into the address bar — goes out over plain http before the redirect to https happens. On a hostile network that first unencrypted request can be intercepted and the user funnelled to a fake site (an SSL-stripping attack). HSTS removes that window after the first visit. The directives are:

• max-age — how long, in seconds, the browser should remember to force HTTPS. One year (31536000) is the common production value.
• includeSubDomains — apply the policy to every subdomain too. Powerful, but it will break any subdomain that is not yet HTTPS-only.
• preload — a request to be baked into browsers' built-in HSTS preload list, so HTTPS is enforced even on the first ever visit. Eligibility requires max-age of at least one year plus includeSubDomains and preload.

The one caution is that HSTS is sticky by design. A long max-age you cannot easily revoke means you must be sure every covered host serves valid HTTPS before you commit, especially with includeSubDomains and preload. Start with a short max-age, confirm nothing breaks, then ramp it up.

Common use cases

• Verifying HTTPS enforcement — confirm a site cannot be downgraded to http after the first visit.
• Checking preload readiness — see whether the policy meets the max-age, includeSubDomains and preload requirements before submitting to the preload list.
• Post-deploy verification — confirm an HSTS change actually reached production.
• Security audits — record the HSTS policy of a site or its vendors as part of a review.
• Debugging a missing policy — find out why a "secure" site still allows an insecure first request.

Rolling out HSTS safely

Because HSTS is hard to undo once browsers have cached it, deploy it in stages:

• Step 1 — short max-age. Start with something like max-age=300 (5 minutes) on the main host only. Confirm the site still works and nothing forces http.
• Step 2 — raise max-age. Move to a day, then a week, then a year as you gain confidence.
• Step 3 — includeSubDomains. Only add this once every subdomain (including internal and legacy ones) serves valid HTTPS, or those subdomains will become unreachable.
• Step 4 — preload. Add the preload directive and submit the domain to the preload list. This is the strongest setting and the hardest to reverse, so do it last and only when you are certain.

This checker shows where a site is along that path, so you can confirm each step landed before moving to the next.