HSTS vs HSTS Preloading

Standard HSTS protects repeat visitors by telling browsers to always use HTTPS for your domain. Preloading goes further by adding your domain to a list hardcoded into every browser, protecting even the very first visit.

Quick Comparison

Feature	Standard HSTS	HSTS Preloading
Protects first visit?	No. Browser must receive the header at least once.	Yes. Domain is in the browser's built-in list.
Header required?	Yes. Strict-Transport-Security header on every HTTPS response.	Yes, plus preload directive and submission to hstspreload.org.
Covers subdomains?	Only if includeSubDomains is set.	Always. includeSubDomains is required for preloading.
Reversible?	Yes. Remove the header or set max-age=0.	Technically yes, but removal from the preload list takes months and requires a browser release cycle.
Time to take effect	Immediate on next visit after receiving the header.	Weeks to months (submission, review, inclusion in browser builds, user updates).
Browser coverage	Only browsers that have visited your site.	All browsers that ship the preload list (Chrome, Firefox, Safari, Edge).

Standard HSTS

HSTS (HTTP Strict Transport Security, RFC 6797) works through a response header. When a browser connects to your site over HTTPS and receives the Strict-Transport-Security header, it remembers your domain for the duration specified by max-age (in seconds). For all subsequent requests to that domain, the browser will automatically upgrade HTTP to HTTPS before sending anything over the network.

A typical header looks like: Strict-Transport-Security: max-age=31536000; includeSubDomains. This tells the browser to enforce HTTPS for one year, including all subdomains. The includeSubDomains directive is important because without it, only the exact domain is protected. Subdomains could still be accessed over HTTP.

The limitation is the first visit. The very first time a user types http://example.com or clicks an HTTP link to your site, the initial request goes over plaintext HTTP. An attacker performing a man-in-the-middle attack could intercept this first request and strip the HTTPS redirect (an SSL stripping attack). Only after the browser receives the HSTS header over a successful HTTPS connection is the domain protected on future visits.

HSTS Preloading

The HSTS preload list is maintained by the Chromium project and is used by all major browsers (Chrome, Firefox, Safari, Edge). It is a list of domains that are hardcoded as HTTPS-only. Browsers ship with this list built in, so they enforce HTTPS for preloaded domains even if the user has never visited the site before.

To get on the preload list, your domain must meet several requirements:

• Serve a valid HTTPS response on the bare domain (not just www).
• Redirect all HTTP requests to HTTPS on the same host.
• Include the header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload on the bare domain.
• The max-age must be at least 31536000 seconds (one year).
• The includeSubDomains directive is mandatory.
• The preload directive must be present.

You submit your domain at hstspreload.org. After review, it is added to the Chromium source list, which is then picked up by other browsers in their next release cycles.

The Preload Trade-off

Preloading is a serious commitment. Once your domain is on the list, every subdomain must support HTTPS. There are no exceptions. If you have internal subdomains, development environments, legacy services, or IoT devices that serve content over HTTP, preloading will break them. The browser will refuse to connect over HTTP, and there is no user override for preloaded domains.

Removal from the preload list is possible but slow. You submit a removal request, it gets reviewed, and then it must ship in a new browser release. Users must then update their browser. The full cycle can take several months. During that time, any HTTP-only subdomains remain inaccessible to users whose browsers still have the old preload list.

Preloading also covers all subdomains you might create in the future. If a team spins up staging.example.com or internal-tool.example.com without HTTPS, it will not work in any browser.

Recommendation

Start with standard HSTS. Set max-age to a short value like 300 (5 minutes) and include includeSubDomains. Verify that everything works correctly. No mixed content warnings, no broken subdomains, no internal tools failing. Gradually increase max-age to 3600 (1 hour), then 86400 (1 day), then 604800 (1 week), and finally 31536000 (1 year).

Only preload after you have run at max-age=31536000; includeSubDomains for a meaningful period and confirmed that every subdomain (including ones used by other teams) supports HTTPS. Most sites benefit from HSTS. Only preload if you are confident that every subdomain, including ones that do not exist yet, will always support HTTPS.