HSTS Preload Guide: Requirements, Risks and How to Submit

HTTP Strict Transport Security (HSTS) tells browsers to use HTTPS only. The preload list goes one step further: your domain is hardcoded into the browser, so even the very first visit is forced onto HTTPS. That closes a real gap, and it is also one of the few web settings that is genuinely hard to undo. This guide covers what preloading does, the requirements, a safe rollout and what removal really means. For the header basics, see the HSTS section of the HTTP security headers guide.

What problem preloading solves

A normal HSTS header is only learned after a browser has successfully connected over HTTPS once:

Strict-Transport-Security: max-age=31536000; includeSubDomains

On a first visit, or after the browser's stored policy expires or is cleared, a user typing example.com sends a plain HTTP request. An attacker on the same network can intercept that request and strip the upgrade to HTTPS before the browser ever sees your header. Preloading closes this trust-on-first-use window: browsers ship with a list of domains that must never be contacted over HTTP.

The list is maintained at hstspreload.org and consumed by Chrome, and other major browsers (Firefox, Safari, Edge) derive their lists from it. Updates reach users only when a browser version that includes the new list is released and installed, which is why both addition and removal are slow.

Requirements to be eligible

The submission site checks these automatically. Verify each one yourself first:

1. A valid certificate on the domain, trusted by browsers, covering the apex name.
2. HTTP redirects to HTTPS on the same host. If a request to http://example.com is redirected, the first redirect must go to HTTPS on the same host, not to a different hostname.
3. All subdomains served over HTTPS. If you serve www, it must work over HTTPS too; if a www hostname exists in DNS, it needs a valid certificate and an HSTS header.
4. An HSTS header on the HTTPS apex response with:
5. max-age of at least 31536000 (one year)
6. the includeSubDomains directive
7. the preload directive

The target header looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Requirements are updated occasionally, so check the current text at hstspreload.org before submitting.

Test what you currently send with the HSTS checker, or from a terminal:

curl -sI https://example.com | grep -i strict-transport
curl -sI http://example.com | head -n 5

The second command should show a 301 or 308 redirect with a Location header starting with https://example.com.

The real risk: includeSubDomains is forever

includeSubDomains means every present and future subdomain of your domain must work over HTTPS. For the preload list this applies to the entire domain tree. Consider what that includes:

• staging.example.com running on a test box with a self-signed certificate
• mail.example.com or webmail.example.com with a certificate that nobody renews
• intranet.example.com or router.example.com served only on HTTP inside an office
• Old marketing subdomains pointing at a vendor that only supports HTTP
• dev.example.com apps served at http://localhost-style internal addresses

After preloading, a browser will refuse to open any of those over HTTP, and will show a non-bypassable error if the certificate is invalid. HSTS errors cannot be clicked through. That is the point of the feature, and it is also the way it hurts.

Before you submit, inventory your names. Use the subdomain finder plus your DNS zone export, and test each with the SSL checker or in bulk with the bulk SSL checker. Any subdomain you cannot put on HTTPS is a reason to wait.

A safe rollout

Do not jump straight to the preload header. Escalate in stages and watch for breakage at each one.

1. Fix the basics. Every hostname on HTTPS, redirects in place, no mixed content. Verify with the redirect checker.
2. Start with a short max-age. Send Strict-Transport-Security: max-age=300 for a day or two. If something breaks, browsers forget in five minutes.
3. Increase to a day, then a week, then a month. max-age=86400, then 604800, then 2592000. Add includeSubDomains at the stage where you have confirmed every subdomain works.
4. Move to one year or more, max-age=31536000; includeSubDomains. Run it for a few weeks.
5. Add preload to the header and confirm it appears on every HTTPS response from the apex, including error pages and responses from your CDN.
6. Submit at hstspreload.org. The site shows eligibility errors if anything is wrong.
7. Wait for the status to progress from pending to preloaded, then for browser releases to ship the update.

Where you set the header matters. If a CDN or load balancer terminates TLS, set it there, or ensure the origin header passes through. Apply it with nginx like this:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

The always flag keeps the header on error responses as well, which matters since a 404 or 500 on the apex still needs it for the preload check.

Removal is slow, so plan as if it is permanent

You can request removal, and the process is straightforward: remove preload from your header (or stop sending the header), then submit the domain on the removal form at hstspreload.org. The catch is propagation:

• The change must be accepted into the list in the Chromium source.
• It then ships in a browser release, and users must update. Stable browser release cycles are measured in weeks, and some users update late or never.
• Other browsers pull from the Chromium list on their own schedule.

In practice, expect removal to take months to be broadly effective, and in the meantime part of your audience will still see forced HTTPS on every subdomain. That is fine if your HTTPS is solid. It is a disaster if you preloaded and then had to move a subdomain to an HTTP-only service.

Also note that dropping the header from your server does not remove you from the list. Preloaded status is independent of what you currently send, although the submission tool may flag domains that stop sending a compliant header.

Is preloading worth it?

For many sites, a regular HSTS header with a long max-age and includeSubDomains already gives most of the benefit. Preload adds protection for first-time visitors and for users whose HSTS cache was cleared, at the cost of reduced flexibility.

Preload is a good fit if you:

• Run only modern, certificate-managed web services under the domain
• Have automated certificate renewal on every host (see Let's Encrypt renewal failures)
• Are a bank, login provider, admin console, or any high-value target
• Accept that an HTTP-only subdomain will never exist again

Skip it, or wait, if you:

• Have legacy HTTP-only services or devices on subdomains
• Do not control all subdomains (customers or third parties using CNAMEs under your domain)
• Cannot guarantee certificates will renew for every name

Remember that HSTS applies to hostnames, not ports. Browsers that see HSTS for example.com will upgrade http://example.com:8080 to https://example.com:8080 too, which can break non-standard port services.

Monitoring after preload

• Watch certificate expiry on the apex and every subdomain. The uptime monitor includes SSL expiry alerts.
• Check the header regularly with the HSTS checker and the security headers checker. A CDN change that drops the header is a quiet regression.
• Use domain expiry watch. If your domain lapses and someone else registers it, the preloaded HTTPS-only status stays attached to the name.

अगले कदम

• Check your current header with the HSTS checker and the full set with the security headers checker.
• Verify redirects with the redirect checker.
• List every subdomain with the subdomain finder and test certificates in bulk.
• Read the HTTP security headers guide for the other headers to add next.

सामान्य प्रश्न

Can I preload a subdomain only?

The list is built for registered domains and their subtrees. Preloading is normally done at the apex with includeSubDomains. Check hstspreload.org for current rules on subdomain-only submissions.

What happens if my certificate expires on a preloaded domain?

Browsers show a full-page error with no option to proceed, for the apex and all subdomains. Fix it by installing a valid certificate; there is no workaround for visitors.

Does HSTS help SEO?

HSTS is not a ranking factor. It removes the HTTP-to-HTTPS redirect hop for returning visitors, which saves a small amount of time, but the main benefit is security.

How long should max-age be?

At least one year (31536000 seconds) for preload eligibility. Many sites use two years (63072000). During testing, start much shorter.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.