HSTS Preload: How to Submit Your Site and How to Safely Remove It

What HSTS does, and why preload matters

Plain HSTS works like this. A browser loads your site over HTTPS, your server sends Strict-Transport-Security: max-age=31536000; includeSubDomains, and the browser remembers for a year. Every future request to your origin (or its subdomains) is upgraded to HTTPS automatically, and the user cannot click through a cert warning. The hole is the first visit: if a user types example.com on coffee shop wifi and an attacker is on the network, that first hop is still attackable because the browser has no HSTS record yet.

Preload closes that gap. Your domain is compiled into the browser, so the first request from any fresh install goes over HTTPS. That is the upside. The downside is that your domain lives inside browser binaries, so changes propagate slowly.

Prerequisites, in order

1. Valid certificate on the apex and on every subdomain that resolves. No self signed, no expired.
2. Redirect HTTP to HTTPS on the apex (301 or 308, same host).
3. Serve this header on the apex:

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

4. Test every subdomain you have: mail, api, dev, staging, blog. They must all serve HTTPS successfully.
5. Only then go to hstspreload.org, enter your domain, and submit.

Common mistakes

• Missing a subdomain. includeSubDomains covers all of them. If mail.example.com lives on a legacy box without HTTPS, preload will still get submitted but users on fresh browsers will not be able to reach that box at all.
• Short max age. Preload submission requires at least one year (31536000). A short value gets rejected.
• Missing the preload token. Without the literal preload directive the submission fails validation.
• Redirecting the apex to www before HSTS. The apex needs to serve the header on the redirect response as well, over HTTPS, with the correct format.
• Forgetting about internal tools. Preload also blocks staging boxes on your apex domain that do not yet serve HTTPS.

How to safely remove a domain from the preload list

Removal is the part that surprises people. You submit an opt out request on the same site, and then you wait. Browsers pick up the change in their next release, and rollouts are gradual. In practice that means months, and older browser installs may never pick up the removal. While your domain is still on the list, users keep enforcing HTTPS regardless of what your server says.

1. Remove the preload token from your HSTS header. Keep max-age and includeSubDomains unchanged for now.
2. Wait until every browser picks up the new header (at least as long as your previous max-age).
3. Submit the removal form at hstspreload.org. Explain why.
4. Once removal is confirmed and you ship in new browser builds, you can lower or drop max-age. Before that, dropping max age has no effect on users that still have the preload entry.

The practical lesson: before submitting, audit every subdomain you will ever want to serve on that apex. If one of them can never be HTTPS (hardcoded legacy device, third party IoT endpoint), do not preload that apex. Use a different domain for the HTTPS world and keep the legacy one out of it.

How our tool reports HSTS

Our security headers checker and the main HTTPS report both pick up the Strict Transport Security response header, parse max-age, includeSubDomains, and preload, and surface what is missing for eligibility. We do not query the browser preload list in real time, but the parsing matches what hstspreload.org expects, so if the report shows all three components and a valid year long max age, you are ready to submit.