HSTS header checker

What is the HSTS header checker?

The HSTS header checker reviews whether a domain serves the Strict-Transport-Security header and how that header is configured. You enter a URL, and the tool examines the response from the server to see whether the security header is present, what policy it declares, and whether that policy looks like a reasonable configuration. It is a targeted way to verify that your site is actively enforcing HTTPS connections.

Strict-Transport-Security, usually shortened to HSTS, is a header a server sends to tell browsers to use HTTPS for that domain going forward, instead of ever connecting over plain HTTP. It is one of the most effective protections against downgrade attacks and hijacking, but only if the header is present and set with the right directives. The checker exists to confirm both halves of that requirement.

For anyone responsible for a website, security auditors, or developers hardening their stack, this checker is a quick health check on whether the transport-layer protection is actually deployed. Rather than remembering the exact syntax and directives, you get a verdict on the live response your domain is serving right now. The header is a quiet part of website security. It does not show up in the browser toolbar or in page content, so a missing or misconfigured policy can go unnoticed for a long time. That invisibility is precisely why a dedicated check matters: HSTS is one of those protections that only works reliably if you verify it, because nothing in the normal experience of a site will warn you when it is absent.

What the HSTS header checker does

The tool requests the URL you provide and reads the response headers that come back. Its first job is binary: does the domain emit a Strict-Transport-Security header at all. Many sites assume they are protected because they redirect HTTP to HTTPS, but that redirect alone does not enforce the policy in the durable way HSTS does.

When the header is present, the tool reviews its configuration. That means looking at the directives declared, such as the max-age value that tells browsers how long to remember the HTTPS-only policy, whether includeSubDomains is set to extend enforcement to subdomains, and whether a preload directive is present. These details determine how aggressively and how long the protection holds.

The output summarizes the configuration in readable terms, so you can see at a glance whether the policy is strong, whether it applies to subdomains, and how long browsers will enforce it. If the header is missing, the tool reports that clearly, saving you the step of inspecting raw server output.

Because the checker reads the live response, it works for debugging too. If you recently added HSTS but the header does not show up, the tool tells you your change did not reach the response, giving you a concrete signal to chase in your CDN or server configuration.

The check is also a teaching tool in the sense that it shows how the header is actually configured in the wild. Seeing the directives spelled out, max-age, includeSubDomains, preload, each in its place, makes it easier to reason about what a good configuration looks like and to spot when a header is weaker than it should be.

For teams managing many domains, the checker also standardizes the definition of done. Instead of relying on individual memory about whether each site was set up correctly, a quick check against each domain gives a uniform, repeatable answer. That consistency is valuable when domains change hands, servers get rebuilt, or a new person joins the team and needs to know the current state of transport security.

How to use the HSTS header checker

Using the checker is fast and works best when you have a specific domain or environment in mind. The steps below take you from entering a URL to acting on the result.

1. Enter the full URL of the domain you want to check, including the protocol, and run the check against the live server response.
2. Read whether the Strict-Transport-Security header is present, since a missing header is the most common finding and the clearest place to start fixing things.
3. If the header exists, review the configured directives, focusing on the max-age value and whether includeSubDomains is applied to your subdomains.
4. Compare what you see with what your team intended to deploy, flagging any difference as a configuration bug rather than an implementation detail.
5. Re-run the check after any change to your server, CDN, or security headers to confirm the fix actually shows up in the live response.

How to get better results

• Check the bare domain and the www variant separately, since the header may be configured differently depending on where the request lands.
• Use a real max-age that can be sustained, because a tiny value forces browsers to keep re-verifying and effectively weakens the protection the header is meant to provide.
• Consider whether includeSubDomains is right for your setup, since it extends enforcement to every subdomain, which is powerful but depends on all of them supporting HTTPS.
• Verify the header after you introduce or change a CDN, because intermediaries sometimes strip or rewrite response headers and silently disable your enforcement.
• Retest after certificate changes or domain migrations, since those moves frequently disrupt the transport security policy even when the site appears to work.
• Pair the check with a look at your redirects, because HSTS works alongside redirects and the two need to agree before the policy is trustworthy.

Why HSTS header checker matters

HTTPS has become the default expectation for websites, but serving over HTTPS is only half the story. Without HSTS, a browser will happily accept a plain HTTP connection on a later visit, which creates a window where the connection can be tampered with before any encryption happens. HSTS closes that window by making the HTTPS-only policy a remembered rule rather than a request-by-request decision.

Because that protection depends on configuration details, verification matters. A header with an absurdly short max-age or one that omits important directives is nearly as risky as no header at all, and the difference is invisible unless you inspect the response. The checker turns that invisible state into a readable diagnosis.

It also fits into a broader security routine. Transport security is a baseline that reviewers and auditors check, and being able to produce concrete evidence about your HSTS configuration saves time in audits and interviews. For teams running many domains, the checker makes enforcing a standard policy across all of them a simple, repeatable task.

When to use the HSTS header checker

• When you have added or edited the Strict-Transport-Security header and want to confirm it reaches the live response as configured.
• During a security review or compliance audit, to verify and document that your domains actually enforce HTTPS-only connections.
• When you suspect a CDN, proxy, or hosting change may have stripped or altered your security headers without anyone noticing.
• When onboarding a new domain or server, to confirm baseline transport security is in place before the site goes live.

Related SEO Tools

Complete your SEO workflow with these related free tools:

• SERP checker - Get the top search engine results for a keyword.
• Indexed pages checker - Check if a domain is indexed by search engines.
• Website status checker - Check the status and availability of a website. Verify a site is online and responding before sharing or monitoring it.
• SSL checker - Check the SSL status and information of a domain. Review certificate validity, issuer, and expiry for a site.

Related SEO Guides

Learn more about this topic with our in-depth guides:

• Meta Tags Checker vs Google Search Console: Which Shows the Real Data?
• Free SSL Certificate Checker: How to Verify HTTPS

Frequently asked questions

What is the Strict-Transport-Security header exactly?

It is a response header a server sends that instructs browsers to always connect to the domain over HTTPS for a specified period. Its purpose is to prevent connections from downgrading to unencrypted HTTP.

What is the max-age directive doing in the header?

max-age tells the browser how many seconds to remember the HTTPS-only policy for that domain. A longer max-age means the enforcement is remembered longer, which is why security guidance favors substantial values rather than short ones.

Why is a missing header a problem if my site already redirects to HTTPS?

The redirect only works on the visit where it happens. Without HSTS, a separate future connection can arrive over plain HTTP before any redirect is processed, and that unprotected moment is exactly what the header is designed to eliminate.

What does the includeSubDomains directive affect?

When present, it extends the HTTPS-only policy to all subdomains of the checked domain. This is stronger protection, but it only works safely when every subdomain your organization runs is capable of serving HTTPS.

Why does my header not appear even though I added it to my config?

The most common causes are caching by a CDN or proxy, an intermediary rewriting the headers, or the change not being deployed to the server that actually answered the request. Re-checking after clearing those layers usually uncovers where the configuration stopped propagating.

Is HSTS the same as having HTTPS forced?

No. Forcing HTTPS usually refers to a redirect that turns HTTP requests into HTTPS ones. HSTS is a separate instruction that tells browsers to remember the HTTPS-only policy for the domain, which closes the gap between requests where a redirect might never get the chance to run.

Can I remove HSTS once it is set?

Within the limits of what browsers have remembered, you can stop sending the header, and new visitors will no longer learn the policy. Some browsers may also support clearing stored HSTS state on the client side, but removing it from your domain configuration stops teaching new connections the policy.