HSTS Header Generator

Build a valid HTTP Strict Transport Security (HSTS) header in seconds. Choose a max-age preset or enter a custom value, toggle includeSubDomains and preload, and get copy-ready snippets for the raw header, Apache, and Nginx — with a clear preload warning before you lock yourself in.

How to use the HSTS Header Generator

Select a max-age preset or choose Custom and enter the exact number of seconds. This tells browsers how long (in seconds) to remember that your site requires HTTPS. The minimum for HSTS preloading is 31,536,000 (1 year).

Check includeSubDomains to extend the policy to every subdomain of your domain. This is required for preloading, but only enable it if every subdomain — including staging and internal services — is already reachable over HTTPS.

Check preload only if you intend to submit your domain to the HSTS preload list at hstspreload.org. Preloading hard-codes your domain in browsers worldwide so it is always accessed over HTTPS, even on the very first visit. This is extremely difficult to undo — removal from the preload list takes months to propagate. Requirements: includeSubDomains must be set, max-age must be ≥ 31,536,000, and all subdomains must serve valid HTTPS.

The output gives you the raw header value plus server-specific directives for Apache (Header always set) and Nginx (add_header). Paste the appropriate block into your server config and reload.

What is HTTP Strict Transport Security?

HTTP Strict Transport Security (HSTS) is a web security policy mechanism defined in RFC 6797 that instructs browsers to access a site exclusively over HTTPS — never plain HTTP — for a specified duration. Once a browser receives an HSTS header, it will automatically upgrade all future HTTP requests to HTTPS for that domain and refuse to load the page at all if the TLS certificate is invalid (unlike a non-HSTS site where the user might click through a certificate warning). This defeats SSL-stripping attacks and prevents accidental insecure connections.

The max-age directive sets the TTL in seconds. A value of 31,536,000 (one year) is the most common recommendation. includeSubDomains extends the policy to all subdomains, closing the vector where an attacker tricks a user into visiting http://sub.example.com to steal cookies scoped to the parent domain. The preload directive signals intent to submit the domain to browser vendors' built-in preload lists, eliminating the "trust-on-first-use" window for brand-new visitors — but this commitment is essentially permanent for the lifetime of your domain.

Before enabling HSTS, ensure your site has valid, auto-renewing TLS certificates on all endpoints (including subdomains if you use includeSubDomains). Start with a short max-age (e.g., 300 seconds) to test, then ramp up to a year or more once you are confident. Never send an HSTS header over HTTP — only deliver it on HTTPS responses.

Common use cases

• Prevent SSL stripping — Force HTTPS even on links that start with http://, defeating man-in-the-middle downgrade attacks on public Wi-Fi.
• Protect session cookies — Ensure Secure-flagged cookies are never transmitted over a plain HTTP connection, even if the user types http:// manually.
• HSTS preload submission — Build the header that meets the requirements for security header compliance and hstspreload.org submission.
• Subdomain security — Use includeSubDomains to prevent cookie-theft attacks via compromised or HTTP-only subdomains.
• Compliance — HSTS is required by PCI DSS, NIST SP 800-52, and is recommended by OWASP and the UK NCSC secure-by-default guidelines.