Skip to content

HSTS Header Checker

Check Strict-Transport-Security headers, max-age, includeSubDomains, preload readiness, HTTPS redirects, and final response status.

Last reviewed: June 11, 2026

About this tool

Inspect HSTS before HTTPS launches, preload submissions, or security audits so transport security directives are visible on the final response.

HSTS Header Checker focuses on the Strict-Transport-Security response header that tells browsers to keep using HTTPS for a domain. It follows redirects, inspects the final HTTPS response, parses max-age, includeSubDomains, and preload directives, and explains whether the policy is strong enough for production or preload planning.

  • Follows redirect hops and evaluates the final HTTPS response.
  • Parses Strict-Transport-Security max-age, includeSubDomains, and preload directives.
  • Flags missing headers, invalid or short max-age values, missing subdomain coverage, missing preload directives, loops, and HTTPS downgrade risk.

How to use HSTS Checker

Enter a URL, run the check, and review the final response plus redirect chain. Start with whether the HSTS header exists, then check max-age, includeSubDomains, preload, and any HTTPS downgrade or redirect loop warnings before changing server or CDN headers.

When this tool is useful

  • Check production pages before security reviews, HTTPS migrations, or CDN header changes.
  • Validate max-age and includeSubDomains before considering HSTS preload submission.
  • Audit transport security alongside SSL Certificate Checker, CAA Record Checker, and HTTP Header Checker.

Practical tips

  • Start with a shorter max-age during rollout, then increase it after every important hostname is verified.
  • Do not add includeSubDomains until all subdomains support HTTPS reliably.
  • Only add preload when the domain meets preload requirements and the team accepts the long-term commitment.

Examples you can test

These examples show the kind of real input and reviewed output this tool is designed to support. Use them as a starting point before pasting your own production content, then compare the output with the destination system that will use the result. The goal is not only to produce a value, but to make the input assumptions, output format, and review step clear enough that the result can be trusted in a real workflow.

Check production HTTPS

Example input

https://example.com

Expected output

HSTS header, max-age, includeSubDomains, preload, and redirect chain

Useful before security reviews or CDN header changes.

Review preload readiness

Example input

https://www.example.com

Expected output

max-age threshold and preload directive warnings

Preload should only be considered after HTTPS is stable across the domain.

Validation checklist

Run through these checks before copying the result into a CMS, codebase, spreadsheet, campaign, support ticket, or production document. Small formatting differences, unit assumptions, hidden whitespace, and platform-specific rules are common sources of mistakes in quick browser tools, so the final review should happen in the same context where the output will be used.

  • Confirm the final response is HTTPS.
  • Add Strict-Transport-Security on the final HTTPS response.
  • Use a production max-age only after rollout testing.
  • Add includeSubDomains only when every subdomain is HTTPS-ready.
  • Treat preload as a long-term commitment, not a default setting.

Why people use this tool

A site can have a valid TLS certificate but still be vulnerable to first-visit downgrade risk if HSTS is missing. At the same time, enabling a strict policy too early can break subdomains, so a focused checker helps teams stage HTTPS hardening with evidence instead of guesswork.

Related search intents

hsts header checker, hsts checker, strict transport security checker, hsts preload checker, https security header checker.

Frequently asked questions

What does an HSTS header checker validate?

It checks whether the final HTTPS response sends Strict-Transport-Security and parses max-age, includeSubDomains, and preload directives.

Why does HSTS matter?

HSTS tells browsers to keep using HTTPS for a domain after the first secure visit. It helps reduce downgrade and protocol-stripping risks.

What max-age should HSTS use?

A long-term production policy often uses at least 31536000 seconds. Browser preload readiness generally requires at least 10886400 seconds plus other directives.

Should includeSubDomains always be enabled?

Only enable includeSubDomains after every subdomain is ready for HTTPS. Otherwise it can break older or forgotten hosts.

Does this submit my site to the HSTS preload list?

No. It only checks the live header and reports readiness signals. Submit preload requests separately after verifying the domain is ready.

Review and privacy notes

Utiloom reviews tool pages for practical examples, validation checks, browser-side processing notes, and clear limitations before they are promoted in search. Read more about the editorial approach on the About page, check data handling in the Privacy Policy, or contact us if a tool needs correction.

Related tools

Keep the workflow moving

These tools are the closest next steps based on category, keyword overlap, and popular workflow paths.

SEO

CAA Record Checker

Validate certificate authority policy.

Browser tool
SEO

HTTP Header Checker

Check response headers and crawl signals.

Browser tool
SEO

SSL Certificate Checker

Check certificate expiry and trust status.

Browser tool
SEO

AI Citation Readiness Auditor

Check page claims and evidence for AI citation readiness.

Browser tool