HSTS Header Generator
Build an HSTS header while keeping max-age, subdomain scope, and preload consequences visible.
HSTS settings
HSTS uses decimal seconds. Enter 0 only when you intentionally want the receiving browser to forget this host's stored HSTS policy.
Output
Generated HSTS output will appear here.
What the browser remembers after HSTS arrives
A browser that accepts a Strict-Transport-Security header remembers that host as HTTPS-only for the number of seconds in max-age. During that period it upgrades HTTP attempts before making the network request. The policy is learned from an HTTPS response; sending the header over plain HTTP does not establish HSTS.
That memory is why a long value deserves care. A certificate outage, forgotten subdomain, old device endpoint, or internal hostname can become inaccessible instead of falling back to HTTP. HSTS is meant to make that fallback impossible.
Roll out max-age before you commit for a year
A short policy is easier to recover from while you are checking redirects, certificates, mixed deployment paths, and subdomains. The HSTS preload project recommends staged values such as five minutes, one week, and one month before a long-term policy. Waiting through each stage matters because previously cached HSTS state does not disappear when you change the server configuration.
Strict-Transport-Security: max-age=300; includeSubDomains
includeSubDomains is a domain-wide promise
With includeSubDomains present, the policy covers descendants of the HSTS host as well. That can include old applications, internal names, customer-specific subdomains, and hosts managed by another team. A forgotten HTTP-only subdomain is enough to make a broad policy hurt.
Also remember that a child host cannot reliably opt out while it is still covered by an ancestor's active includeSubDomains policy. Sending max-age=0 on the child does not cancel the parent's policy.
Preload is separate from ordinary HSTS
RFC 6797 defines HSTS itself. The preload directive is an ecosystem convention used by browser preload lists. A header containing max-age of at least one year, includeSubDomains, and preload has the required header shape for the current submission service, but that does not make a domain eligible by itself. Certificates, redirects, the base domain, and every subdomain still have to satisfy the service's checks.
The preload project explicitly advises against enabling preload by default because removal can take months to reach users. Treat it as a separate operational decision, not a checkbox that makes HSTS stronger automatically.
What max-age=0 actually removes
A value of zero tells a browser that receives the HTTPS response to stop treating that host as an HSTS host. It does not repair a broken certificate path before the browser can reach the HTTPS response, and it does not override HSTS inherited from a parent domain that is still active with includeSubDomains.
Keep the header and the deployment target separate
Nginx, Apache, a CDN, and a managed host all express response-header rules differently. The generated server snippets only place the same HSTS value into common configuration syntax. They cannot verify that the rule runs on every HTTPS response, survives redirects, or is inherited into nested configuration blocks.
The two references worth checking before a long-lived policy
The protocol behavior comes from RFC 6797. If you are considering preload, read the current HSTS preload requirements and rollout guidance. The preload service can change independently of the RFC, so its live requirements matter more than an old copied checklist.