The max-age directive of the Strict-Transport-Security header tells browsers exactly how long to remember that your site must be accessed over HTTPS only. Getting this value right is crucial: it directly determines how strongly browsers enforce your HTTPS policy and whether your domain qualifies for the HSTS preload list.
What Does max-age Control?
When a browser receives the Strict-Transport-Security header, it stores the policy in an internal cache alongside a timestamp. For every subsequent request to your domain during themax-age window, the browser skips the HTTP-to-HTTPS redirect entirely and connects directly over HTTPS — even before your server has a chance to respond.
This behaviour is what makes HSTS significantly stronger than a plain HTTP 301 redirect. A redirect can still be intercepted on an attacker-controlled network for first-time visitors. HSTS enforcement happens client-side, making it immune to that class of downgrade attack.
The value is expressed in seconds. A value of 31536000 equals exactly one year (365 × 24 × 60 × 60). Each time the browser visits your site and receives the header again, the timer resets to the full max-age from that point.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadRecommended max-age Values
There is no single correct value for all situations. The right choice depends on where you are in the deployment process.
| Stage | Recommended max-age | Seconds | Notes |
|---|---|---|---|
| Initial testing | 5 minutes | 300 | Safe to clear easily if HTTPS breaks |
| Short-term rollout | 1 day | 86400 | Gives a 24-hour observation window |
| Stabilised deployment | 1 month | 2592000 | Good intermediate step |
| Production (recommended) | 1 year | 31536000 | Required for preload list eligibility |
max-age=300 when first deploying HSTS. Verify your site works correctly on HTTPS across all pages, subdomains, and resources before increasing to one year. A phased approach means a configuration mistake only locks out browsers for five minutes, not twelve months.Preload Requirements: Why One Year Is the Minimum
The HSTS preload list, maintained by Google and shipped inside every major browser, hard-codes domains that must always use HTTPS — even on the very first visit, before the site has ever sent the header. This eliminates the "trust on first use" window entirely.
To qualify for submission to hstspreload.org, your domain must meet all of these conditions:
- Serve a valid HTTPS certificate with no errors.
- Redirect all HTTP traffic to HTTPS on the same host.
- Serve the HSTS header on the base domain (not only subdomains).
- Set
max-ageto at least31536000(one year). - Include the
includeSubDomainsdirective. - Include the
preloaddirective.
preload directive in your header is a signal of intent, but the real commitment is the list submission itself.Risks of Too-Short vs Too-Long Values
Too-short max-age
A very low max-age (such as 0 or a few seconds) provides almost no protection. Browsers clear the HSTS entry almost immediately, meaning the site behaves as if it has no HSTS at all for returning visitors who have let any amount of time pass. Attackers can exploit this by intercepting the first unprotected request.
Setting max-age=0 is actually the standard way to remove HSTS from a browser's cache — useful when decommissioning HTTPS, but harmful if used unintentionally in production.
Too-long max-age before you are ready
If you set max-age=31536000 while your TLS certificate is misconfigured, a subdomain still runs on HTTP, or you ever need to roll back to HTTP for maintenance, you will have locked browsers out of your site for up to a year. They will refuse to load your site over HTTP and will show an error page if HTTPS is broken — with no bypass option.
How Browsers Cache the HSTS Policy
Each browser maintains a separate HSTS database. When a browser receives aStrict-Transport-Security header over a valid HTTPS connection, it records the domain, the expiry time (current time plus max-age), and whether includeSubDomainswas set. On every subsequent request to that domain, the browser checks the database before making any network connection. If the entry exists and has not expired, the request is automatically upgraded to HTTPS internally.
The timer refreshes on every visit where the server sends the header again. This means active users of your site will almost never see the HSTS entry expire — it keeps renewing. The expiry only matters for users who have not visited your site in over a year.
How to Clear the HSTS Cache for Testing
During development you will often want to reset the HSTS state in your browser so you can test changes to the header or temporarily access the site over HTTP.
Chrome and Edge
Navigate to chrome://net-internals/#hsts, find the "Delete domain security policies" section at the bottom, enter your domain, and click Delete.
Firefox
Open the browser console on the site (F12), go to Storage Inspector, find "SiteSecurityServiceState" in the application data, and delete the entry for your domain. Alternatively, close Firefox and manually edit the SiteSecurityServiceState.txt file in your profile directory.
Forcing removal via the header
You can also instruct the browser to immediately discard the cached policy by sendingmax-age=0. The browser will delete the entry as soon as it processes the response.
Strict-Transport-Security: max-age=0max-age value, use the ShowDNS HSTS Checker to confirm the header is being served correctly and that the value matches your intention. The tool also reports whether your domain is on the preload list.Frequently Asked Questions
Can I set max-age to a value other than one year?
Yes. The HSTS specification imposes no minimum or maximum (other than the preload list requirement of at least one year). Any positive integer in seconds is valid. Use shorter values during rollout and increase them once your HTTPS setup is stable.
Does max-age affect the preload list entry?
No. The preload list entry itself does not expire — it is a hard-coded list inside the browser binary. The max-age value only controls the expiry of the dynamically cached HSTS policy received from your server. Preload list removal requires a separate submission to hstspreload.org and can take many months.
What happens if my certificate expires while HSTS is active?
Browsers will show a certificate error page and will not allow users to bypass it the way they can bypass a normal HTTP warning. This is intentional — HSTS is designed to make certificate errors fatal. Ensure your certificate renewal process is automated and monitored before setting a longmax-age.
Should I use the same max-age for includeSubDomains?
The max-age value applies to the entire policy including subdomains ifincludeSubDomains is present. There is no way to set different expiry times for the root domain and subdomains within a single header. Ensure every subdomain has a working HTTPS configuration before enabling includeSubDomains with a long max-age.
How can I check what HSTS value my browser has cached?
In Chrome or Edge, visit chrome://net-internals/#hsts and use the "Query HSTS/PKP domain" form to look up a specific domain. The output shows the stored expiry and whether the entry came from the preload list or from a dynamic header.