HSTS Preload Checker

Server assisted New Internet Security & Privacy

Enter a domain and the Mutqan server requests its https:// and http:// addresses once each and asks hstspreload.org for the domain's list status and the blocking issues its own check finds. Every submission requirement — a valid certificate, an HTTP-to-HTTPS redirect on the same host, a header with max-age of at least a year, includeSubDomains and preload — is shown with what was actually observed. You can also paste a header value to check it in your browser.

Privacy: The domain, address or URL you enter is sent from the Mutqan server to the public data service named on this page (a registry, a resolver, a certificate log or a measurement network). Nothing is stored.

What is HSTS preloading and what does a domain need to qualify?

HSTS (RFC 6797) is a response header that makes a browser use HTTPS for a host for max-age seconds after its first secure visit; the preload list, built into Chromium and the lists other browsers derive from it, extends that protection to the very first visit. To be accepted, a domain must serve a valid certificate, redirect HTTP to HTTPS on the same host, serve every subdomain over HTTPS, and send the header with max-age of at least 31536000, includeSubDomains and preload.

Security note: Preloading cannot be undone quickly: a removal reaches visitors only as their browsers update. Every subdomain, including internal tools and ones created later, must work over HTTPS before you submit.

How to use HSTS Preload Checker

  1. Enter the domain (example.com); a URL or a www. name is reduced to the domain.
  2. Press Check HSTS and read the preload status, then the six requirements.
  3. Fix anything marked Not met, starting with HTTPS and the redirect, and read hstspreload.org's own blocking issues when they are listed.
  4. To check a header before deploying it, paste the value into the second field instead; nothing is sent.

HSTS Preload Checker features

  • Checks a domain against the published hstspreload.org submission requirements: HTTPS with a valid certificate, an HTTP-to-HTTPS redirect on the same host, and a Strict-Transport-Security header with a max-age of at least one year, includeSubDomains and preload
  • Asks hstspreload.org for the domain's current list status — preloaded, pending, removed, rejected or not listed — and for the blocking issues its own crawler reports
  • Shows what the Mutqan server actually saw: the status of the https:// and http:// responses, the redirect target and the raw header
  • Keeps "Not met" apart from "Not verified": a request that timed out or was refused says nothing about the site and is never counted as the site's failure
  • Checks a pasted Strict-Transport-Security value in your browser: its directives, max-age in seconds and days, repeated or malformed directives and unknown ones
  • Lists what to fix in order, and warns before submission that preloading is slow to undo

Inputs and outputs

Inputs

  • Domain — a registrable domain such as example.com; a URL or a www. prefix is reduced to the domain. Single-label names, IP addresses and private names are refused.
  • Pasted header — a Strict-Transport-Security value, with or without the header name; it is checked in your browser and the domain field is ignored.

Outputs

  • Summary — the preload status, how many of the six requirements are met and how many could not be verified, max-age in days and whether the domain looks ready to submit.
  • Preload requirements — each requirement with Met, Not met or Not verified and the value observed.
  • Preload list and hstspreload.org issues — the list's own status word, the domain it is preloaded through, when it was asked, and its blocking issues and warnings in that service's own words.
  • What the Mutqan server saw, header directives and header problems — the two responses, the raw header and any grammar problem in it.

HSTS Preload Checker example

A domain that is ready except for the preload directive

Input:

example.org

Output:

Preload status: Not preloaded · Requirements met 5/6 · max-age (days) 365 · Ready to submit: No
HTTPS with a valid certificate — Met — HTTP 200
HTTP redirects to HTTPS on the same host — Met — HTTP 301 → https://example.org/
Strict-Transport-Security header — Met — max-age=31536000; includeSubDomains
max-age of at least one year — Met — 31536000 s (365 d)
includeSubDomains directive — Met — Present
preload directive — Not met — Not present
hstspreload.org issues: Blocking · header.preloadable.preload.missing · No preload directive

How to read the HSTS Preload Checker results

"Preloaded" means browsers ship the domain in their built-in list and use HTTPS for it and all its subdomains even on a first visit. "Pending inclusion" means it has been accepted and waits for browser releases.

"Ready to submit: Yes" needs all six requirements met and no blocking issue from hstspreload.org, whose own crawl also checks subdomains such as www and redirect chains — its answer decides. When hstspreload.org could not be asked, or a requirement could not be verified, the answer is Unknown rather than Yes or No; "Already submitted (pending)" means the domain is waiting for inclusion.

"Not verified" is not a failure of the site: the Mutqan server could not finish that request (a time-out, or an address it may not connect to). When no HTTPS response arrived at all, the four header requirements are Not verified too, because the header was never seen. Run the check again, or verify from your own network.

A max-age below 31536000 seconds (365 days) still protects returning visitors for that long, but the preload list does not accept it; max-age=0 tells browsers to forget the policy.

When to use HSTS Preload Checker

  • Preparing a domain for submission to the HSTS preload list and seeing exactly which requirement is missing.
  • Checking that a new HTTPS deployment sends Strict-Transport-Security on the apex and redirects HTTP correctly.
  • Confirming whether a domain is already preloaded, pending or removed before changing its HTTPS setup.
  • Reviewing a header value in a pull request before it reaches production.

Troubleshooting

  • The redirect is Not met although the site ends on HTTPS: the first hop from http:// must go to https:// on the same host. A redirect straight to https://www. (another host) is not accepted; redirect to https://example.com/ first.
  • The header is Not met although your server sends it: it must be on the HTTPS response of the apex itself, not only on www or on deeper pages, and browsers ignore it on plain-HTTP responses.
  • A refusal that says the domain "has no A or AAAA record" or "resolves to an address the Mutqan server may not connect to": the name does not resolve publicly or points to a private address. Only public domains can be checked, and only they can be preloaded.
  • Preload status "Unknown — hstspreload.org not reached": the list service did not answer, but the requirement rows still come from the Mutqan server's own requests. Try again later.

Frequently asked questions about HSTS Preload Checker

What does HSTS preloading do?

It puts the domain into a list that browsers ship built in, so they use HTTPS for it — and for every subdomain — even on the very first visit, before any header could have been seen. Without preloading, the first request of a new visitor can still go over plain HTTP.

Why is the preload directive required?

It is the site owner's consent: preloading affects every subdomain and is slow to undo, so the list only accepts domains whose own header asks for it with preload, together with includeSubDomains and a max-age of at least one year.

Can I remove my domain from the preload list later?

Yes, through hstspreload.org, but the removal reaches visitors only as their browsers update, which takes months, and some will keep the old list longer. Until then every subdomain must keep working over HTTPS.

Why does the check say "Not verified" instead of "Not met"?

Because the Mutqan server could not finish that request: it timed out, or the address is one it may not connect to. That says nothing about your site, so it is not counted as a failure. When no HTTPS response arrived, the four header requirements are Not verified as well, because the header was never seen. Run the check again or test from your own network.

Does the check test my subdomains?

No. It fetches only the apex over HTTPS and HTTP. hstspreload.org's own check does look at subdomains such as www and at redirect chains, and its blocking issues are listed as it reports them.

Technical notes

HSTS is defined by RFC 6797: once a browser has received a valid Strict-Transport-Security header over HTTPS, it rewrites every http:// request to that host to https:// for max-age seconds and does not let the visitor click through certificate errors; includeSubDomains extends this to every subdomain.

The header grammar of RFC 6797 §6.1 is applied: directives are separated by semicolons, names are case-insensitive, max-age is required and must be a whole number of seconds (quotes allowed), no directive may appear twice, and unknown directives are ignored. preload is not in the RFC; it is the token the preload list asks for.

The preload list is compiled into Chromium, and Firefox, Safari and Edge maintain lists based on it. Its submission rules (hstspreload.org): a valid certificate; a redirect from HTTP to HTTPS on the same host before any other redirect, when port 80 answers; every subdomain served over HTTPS; and the header on the HTTPS response of the domain with max-age of at least 31536000, includeSubDomains and preload.

The Mutqan server makes two requests to the apex, https:// and http://, without following redirects or reading a body, and two calls to the hstspreload.org API (status and preloadable) whose answer is cached for 24 hours. A refused connection on port 80 counts as "no service", which the list accepts; a time-out counts as not verified.

Limitations and methodology

Only the apex is fetched (https://domain/ and http://domain/), from the Mutqan server on Cloudflare's network. Subdomains are not tested here; hstspreload.org's crawl tests them, and its blocking issues are listed as it reports them.

hstspreload.org answers are cached for up to 24 hours, so a change made minutes ago may show in the list status only the next day; the requirement rows always come from live requests.

Browsers take the list with their own releases: a domain accepted today reaches users weeks to months later, and a removal takes as long.

Security and privacy

The domain is sent to the Mutqan server, which makes two requests to it and asks hstspreload.org about it; nothing is stored. A pasted header is checked in your browser and never sent.

References