We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Check your website's HSTS configuration status, analyze security header parameters, and enhance HTTPS strict transport security.
Uses testssl.sh HTTP-header checks with the reported version, not the old direct-fetch endpoint. HSTS/max-age must appear explicitly; missing is unknown. Does not confirm preload, every subdomain/path/redirect, or overall site safety. Reference
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
HTTP Strict Transport Security (HSTS) is a policy a web host communicates with the Strict-Transport-Security response header. A browser that accepts the policy remembers that the host should be reached over HTTPS for the stated period. RFC 6797 defines this behavior and the header’s max-age directive.
Enter a hostname and run the headers check. The result reports the scanned host, port and resolved IP, then lists returned findings. If an HSTS finding is recognized, the page labels it enabled or disabled and may show the max-age value. If no HSTS finding is recognized, or the finding cannot be interpreted, the page reports that it was not found or the status is unknown.
The max-age directive gives the policy lifetime in seconds. The displayed number is the value found in the reported finding; it is not a security grade. A nonzero value is treated as enabled by the summary, while zero is not. Review the full finding text and scan details alongside the summary.
A single remote headers scan does not prove that every route, subdomain, browser, or network path receives the same response. This page does not report preload-list membership or provide a full TLS, certificate, application, or security assessment. The HSTS policy also does not address phishing or malware; RFC 6797 describes those as outside its threat scope.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Enter the host name you want to inspect, such as example.com. The check runs remotely against that host.
Start the test and wait for the returned scan findings.
Read the HSTS summary together with the host, port, resolved IP and full finding text. Note the reported max-age seconds when present.
If the status is missing or unknown, compare the result with the response the intended users receive and repeat the check for relevant hosts or routes.
Use cases
See how the tool fits into real work and everyday tasks.
A site administrator can check whether the scanned host returns a recognizable HSTS finding after a configuration change, then inspect the reported value against the intended policy.
A developer can use the host, port and finding text as a quick diagnostic before investigating different routes, subdomains or deployment environments separately.
Q&A
Find concise answers to common questions and confusing cases.
No. It describes a recognized HSTS finding from this scan; it is not a complete website-security audit.
No. The result is a headers check and does not report preload-list membership.
Responses can differ by host, route, port, or deployment path. This scan reports the response it received for the submitted host; check the exact user-facing path separately.
It is the policy lifetime in seconds that a conforming browser uses for the host, as defined by RFC 6797.
Notes
Review scope, result limitations, and important precautions before use.
Use scan output as a point-in-time diagnostic. Confirm the actual response headers for the paths and subdomains that matter, and verify configuration changes in your own deployment process. HSTS can affect browser access when HTTPS has errors, and this check cannot assess whether enabling a policy is appropriate for your full domain structure.
Related
Discover related tools, collections, and available API capabilities.