DNS Tools
TRANSPORT POLICY

HSTS Checker

Check whether your site sends Strict-Transport-Security, how long browsers will remember it, and whether it meets the HSTS preload header requirements.

Run HSTS

The domain (or a subdomain). The check stays within that name and its www counterpart, like the full assessment.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What HSTS does

HTTP Strict Transport Security is a response header that tells a browser to use only HTTPS for a host for a stated time. After a browser has seen the header over HTTPS, it converts later http:// requests for that host into https:// before any packet leaves, which removes the window in which an attacker could intercept the first plain-HTTP request or downgrade the connection. The header is ignored when received over HTTP, so a working HTTPS site is required first.

This tool reads the header on every response in the chain, shows which host sent it, parses the directives, and evaluates the host where a visitor lands.

How to read the results

A table lists each host reached with its status, header, max-age, includeSubDomains and preload flags, and any parsing issues.

  • max-age: seconds the browser remembers the policy. The assessment's threshold is 15552000 seconds, six months; a year is common.
  • includeSubDomains: extends the policy to every subdomain. Useful, but see the caution below.
  • preload: a token indicating willingness to be included in browser preload lists. It does nothing by itself.
  • Per-host scope: HSTS protects only the host that sent it. A header on www does not protect the apex unless it also sends one.
  • Syntax issues: a repeated directive makes browsers ignore the whole header; a missing or non-numeric max-age voids it.

Preload eligibility and the cautions

The preload lists shipped inside browsers apply HSTS before a first visit. The header requirements are a max-age of at least one year (31536000), includeSubDomains, the preload token, and an HTTP to HTTPS redirect on the same host. The tool shows each requirement as met or unmet as reasoning from the header only. It does not query the preload list and makes no claim about membership; the official preload site is the place to check status.

Caution: includeSubDomains forces HTTPS for every subdomain, including ones you may have forgotten: an internal tool, a legacy host, an intranet name that only serves HTTP, or a marketing platform on a CNAME. Those become unreachable in browsers that have seen the policy. Preloading is much harder to reverse than the header, because removal from the list and from shipped browser releases takes a long time. Do not preload until every subdomain, now and planned, supports HTTPS.

Common problems

  • No header: the host does not tell browsers to stay on HTTPS.
  • Short max-age set during testing and left in place.
  • Header only on some hosts: the apex sends it, www does not, or reverse.
  • Header sent over HTTP only, which browsers ignore.
  • includeSubDomains added too early, breaking HTTP-only subdomains.
  • Duplicate directives from two layers each adding the header.

How to roll out HSTS safely

Prerequisites: working HTTPS with a valid certificate on the host and every subdomain you will cover, and an HTTP to HTTPS redirect. Risk: after browsers store the policy, they will refuse to connect over HTTP until it expires, and certificate problems become hard failures with no click-through. Rollback: send max-age=0 over HTTPS to clear the policy for browsers that visit again; those that do not return keep it until expiry.

  1. Confirm every name you serve works on HTTPS and the certificate renews reliably.
  2. Start with a short max-age such as 300 seconds and no includeSubDomains. Check for problems.
  3. Increase in stages to a day, a week, a month, then at least six months.
  4. Audit every subdomain before adding includeSubDomains.
  5. Consider preload only as a deliberate, long-term decision.

Limits

Preload list status is not queried. Only the first occurrence of a repeated header is examined. Error and redirect responses are not judged because their headers are not representative. The tool judges one response from one location, and the port 80 redirect that preload requires is covered by the redirect checker.

Frequently asked questions

Does HSTS replace the HTTP to HTTPS redirect?

No. The redirect handles the first visit and clients that ignore HSTS; HSTS handles later visits.

Is 15552000 seconds the right max-age?

It is the minimum this tool treats as healthy. One year is common and is required for preload.

Is includeSubDomains safe to add?

Only if every subdomain, including forgotten ones, serves HTTPS correctly. Audit first.

How do I remove HSTS?

Serve max-age=0 over HTTPS. Browsers update when they next visit; preloaded entries need a separate, slow removal process.

Why does the tool not say whether I am preloaded?

It does not query the list. Check the official preload site for status.

Why does HSTS on www not protect example.com?

HSTS is scoped to the host that sends it, plus its subdomains if includeSubDomains is set.

Scope of this tool

  • Only the domain's apex and www host are contacted over HTTPS (and port 80 where stated); redirects to any other host are reported, never followed.
  • Spectra identifies itself honestly and does not imitate a browser, so sites that block automated clients may not show their real headers.
  • A single request path (/) is examined from this scanner's network position; other pages, other nodes of a load-balanced site and other regions may differ.
  • If a header is sent more than once, only the first occurrence is examined.
  • Error and redirect responses are not judged: their headers are not representative of the site.

Written by DNS Tools editorial · Last updated 2026-10-09