Test HSTS Headers Online

HSTS Tester for Strict-Transport-Security Validation

This HSTS tester is for checking whether a site is actually returning the Strict-Transport-Security header and whether the policy looks plausible for the URL you are testing. That matters in security reviews, deployment validation, CDN or reverse-proxy changes, and post-migration checks where HTTPS should be enforced consistently.

The page is not a full security audit. It is a focused browser-side header check for one important security policy. That narrow scope is useful because HSTS mistakes are often simple: the header is missing, the max-age is too short, subdomains are not included, or the behavior differs between environments.

Key Features

• Check whether a public URL returns the Strict-Transport-Security header.
• Useful for confirming HSTS presence and reviewing core directive values.
• Helps catch obvious misconfigurations after server, proxy, CDN, or certificate changes.
• Good for deployment validation, security spot checks, and environment comparisons.
• Pairs naturally with HTTP Header Checker and HTTP Response Codes.

Use Cases

• Verifying that a production site actually sends HSTS after an HTTPS hardening change.
• Checking whether a staging or edge environment differs from the expected security-header policy.
• Reviewing HSTS behavior after a load balancer, CDN, or reverse-proxy update.
• Confirming whether subdomain coverage or preload-related expectations are visible in the returned header.

How To Use

1. Enter the full public URL you want to test.
2. Run the check and review whether the Strict-Transport-Security header is present.
3. Inspect the returned directive values and make sure they match the policy you expect.
4. Compare environments when necessary instead of assuming staging and production behave the same way.
5. If you need broader response visibility, continue into HTTP Header Checker.

A good practice is to test the exact hostname users hit, not just an origin server you happen to know. Security headers often change across proxies and delivery layers.

How It Works

The page requests the target URL and inspects the returned headers for Strict-Transport-Security. The useful result is not only whether the header exists, but whether the visible directives align with the intended HTTPS policy.

That distinction matters because partial HSTS coverage can create a false sense of completion. A site may serve HTTPS correctly while still missing the header on the hostname or path you actually care about.

Examples

Post-deployment verification

A security ticket says HSTS was enabled in production. Use the page to confirm the header is actually being returned from the live hostname.

Environment comparison

A staging site and production site should behave the same way, but one may still be missing a header after a proxy change. Testing both quickly reveals the gap.

Change management check

After a CDN or certificate rollout, use a focused HSTS test before closing the task so the browser-side policy was not accidentally dropped.

Edge Cases & Troubleshooting

• A valid HTTPS site is not the same thing as a site with HSTS configured correctly.
• If the header appears on one hostname but not another, check redirects, edge layers, and canonical host behavior.
• HSTS presence alone does not confirm every security header or HTTPS hardening decision on the site.
• If the result is inconsistent, test the exact public URL path and hostname users reach, not only the origin.

FAQ

What does HSTS do?

HSTS tells supporting browsers to use HTTPS for a site and avoid falling back to insecure HTTP after the policy has been seen.

What should I look for in the result?

Start with whether the header exists at all, then review whether the directive values match the policy your team intends to enforce.

Does this page replace a full security scan?

No. It is a focused header check for HSTS, not a full website security assessment.

What should I use next if I need more detail?

Use HTTP Header Checker for broader header inspection and HTTP Response Codes for status-code interpretation.

Next Steps / Related Workflows

• Use HTTP Header Checker to inspect the full response header set after checking HSTS specifically.
• Use HTTP Response Codes when the returned status itself needs interpretation during troubleshooting.
• Retest after edge, proxy, or certificate changes instead of assuming the HSTS policy stayed intact.