search

Found

info Overview

Generate a ready-to-paste Strict-Transport-Security header and validate it against five Chromium preload-list rules from your max-age and directives.

📘 How to Use

  1. Choose a max-age from the presets or enter a custom value in seconds
  2. Toggle includeSubDomains and preload as your policy requires
  3. Read the generated Strict-Transport-Security header and the eligibility checks

HSTS Policy Builder & Validator

Before enabling preload, confirm that includeSubDomains can stay enabled permanently.

Strict-Transport-Security: max-age=31536000
Copied!

Preload-list eligibility checklist

    Submit at hstspreload.org. Once accepted, the policy is cached by browsers and removal takes months.

    ※ A staged rollout (300 s → 1 day → 1 week → 1 month → 1 year) keeps the cost of a rollback small.

    ※ HSTS is defined by RFC 6797; preload-list eligibility follows the Chromium project policy at hstspreload.org.

    grid_view Related

    Article

    HSTS Policy Builder & Validator | Header String + Preload Eligibility in One View

    Pick a max-age, flip includeSubDomains and preload, and get a ready-to-paste Strict-Transport-Security header plus a five-point PASS / FAIL / WARN check against the Chromium preload-list rules.

    💡 About this tool

    HTTP Strict Transport Security (HSTS) is a single response header that tells browsers "always use HTTPS for this domain." Writing the header is the easy part. The part that trips people up is the preload list: a curated list, maintained by the Chromium project, that browsers ship with built in. Get your domain on it and HTTPS is enforced before the user ever makes a request — but submission requires max-age of at least one year (31536000 seconds), the includeSubDomains directive, and the preload directive, all present at once.

    Submit a header that misses any of those and hstspreload.org rejects it, costing you a fix-and-resubmit cycle. Worse, adding preload without understanding it forces HTTPS on every subdomain you own — internal dashboards and that old legacy. host included — and people get locked out. This tool puts the header builder and the eligibility checklist side by side so you can confirm, before you submit, that your header meets the rules and that you haven't created a contradictory combination such as max-age=0 together with preload.

    The presets cover 0 (unset), 5 minutes, 1 day, 1 week, 30 days, 180 days, 1 year, and 2 years. For a first rollout, the safe move is to start with a short value and ramp up.

    🧐 Frequently Asked Questions

    Q. What's the minimum max-age for the preload list? A. Submission requires at least 31536000 seconds (1 year). Watch for the "max-age is at least 31536000 seconds" row to flip to PASS. The 180-day value (15552000 s) falls short of the 1-year requirement, so it is not enough for submission.

    Q. What does max-age=0 actually do? A. It tells browsers to clear any stored HSTS policy for the host — useful when you want to back HSTS out. Combine it with preload and you get a contradiction, which is why that pairing shows FAIL in the checklist.

    Q. What's the blast radius of includeSubDomains? A. It applies the policy to every subdomain, not just the apex. It's mandatory for preload, but any subdomain that isn't on HTTPS becomes unreachable, so inventory your subdomains before you turn it on.

    Q. Can I undo a preload submission? A. You can request removal, but browser caches take months to catch up. Treat preload as effectively one-way and decide accordingly.

    Q. Why ramp max-age gradually instead of jumping to a year? A. A short value keeps your rollback cost small if you find a misconfiguration. The common ladder is 5 min → 1 day → 1 week → 1 month → 1 year.

    📚 Fun Facts

    HSTS itself is specified in RFC 6797, but the preload list is not part of any RFC — it lives as a public Chromium project policy at hstspreload.org. So you're really dealing with two layers: a standardized header, plus a browser-vendor-driven list bolted on top.

    That list isn't Chrome-only. Firefox, Safari, and Edge all ingest it, so a single submission ripples out to every major browser. A trick you'll see in security threads: register a freshly bought domain on the preload list immediately, so HTTPS enforcement begins from a state with no prior plain-HTTP history attached to it.