All tools

Strict-Transport-Security (HSTS) Header Builder

Network

Build a Strict-Transport-Security response header from a max-age plus includeSubDomains/preload flags, flagging combinations that won't qualify for browser HSTS preload lists, or parse an existing header

Enter a max-age in seconds and choose whether to add includeSubDomains and preload, and get back the assembled Strict-Transport-Security header value plus a plain-English read on whether it qualifies for a browser's built-in HSTS preload list. Preload lists require all three at once: max-age of at least one year, includeSubDomains, and the preload token itself, so this tool checks that combination and warns when one piece is missing. It also parses an existing header value back into its parts, useful for checking what a live response is actually sending. It is pure string assembly and lookup, it never checks whether a domain is actually on the real hstspreload.org submission list.

httpheaderssecurityhstshttpstls

How to use Strict-Transport-Security (HSTS) Header Builder

  • 1.Pick a preset or set a custom max-age in seconds, then toggle includeSubDomains and preload as needed.
  • 2.Copy the generated header and add it to your server or CDN's HTTPS response config.
  • 3.Or paste an existing Strict-Transport-Security header into the parse box to see its max-age, flags, and preload-list eligibility explained.

Frequently asked questions

What does preload actually do?
Setting the preload directive is only a signal, it does not enroll your domain anywhere by itself. Browser vendors maintain a separate hardcoded preload list (see hstspreload.org) that you submit your domain to once your header meets their requirements; this tool checks those requirements but does not submit anything.
Why is max-age=0 flagged as a warning instead of just building the header?
max-age=0 is a valid header value, but its effect is to tell the browser to forget this host requires HTTPS, which clears HSTS rather than enabling it. It's a legitimate way to roll back HSTS, just not what most people mean when they reach for this tool.
Does this affect plain HTTP responses?
No. Browsers only honor the Strict-Transport-Security header when it arrives over a connection already secured with HTTPS; the same header sent over plain HTTP is ignored entirely, since trusting it would defeat the point.
What max-age should I actually use in production?
There's no universal answer, but a common path is to start low (a day or so) while confirming HTTPS works everywhere, then raise it to 6 months to a year, then add includeSubDomains and preload once you're confident every subdomain also serves HTTPS.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/hsts-header-builder \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"maxAge":31536000,"includeSubDomains":true,"preload":true,"header":"max-age=31536000; includeSubDomains; preload"}'

Get an API key from your dashboard · Full API docs →

Related tools

Permissions-Policy Header BuilderBuild a Permissions-Policy (formerly Feature-Policy) response header from a list of browser features and their allowlists (self, none, specific origins, or all origins), with a plain-English note on what each directive restricts, or parse an existing headerNetworkReferrer-Policy Header BuilderBuild a Referrer-Policy header value from one or more policy tokens with a plain-English explanation of each and warnings for risky choices like unsafe-urlNetworkSSL Certificate CheckerInspect SSL/TLS certificates: expiry, issuer, SANs, and fingerprint for any domainNetwork