What Is HSTS Preload? How Browser Preloading Works

HSTS (HTTP Strict Transport Security) tells browsers to use HTTPS after they have visited your site once. But what about the very first visit, before any HSTS header has been seen? HSTS Preload solves this by embedding your domain directly into browsers so they enforce HTTPS from the moment a user types your address — with no initial HTTP request at all.

How HSTS Works Without Preloading

When you enable HSTS on your server, you add the Strict-Transport-Security response header to every HTTPS response. The browser reads this header and caches a rule: for the duration of max-age, always connect to this domain over HTTPS.

The limitation is the trust-on-first-use (TOFU) problem. The very first time a user visits your site — or the first visit after the cached policy expires — the browser may send an HTTP request before being redirected to HTTPS. That brief window can be exploited by a network attacker to perform a downgrade or man-in-the-middle attack.

The first-visit gapHSTS only protects users who have already visited your site at least once and cached the policy. Users visiting for the first time, or after the max-age expires, are not protected by HSTS alone.

What Is the HSTS Preload List?

The HSTS Preload List is a hardcoded list of domains maintained at hstspreload.org and shipped directly inside web browsers — Chrome, Firefox, Safari, Edge, and others. Before a browser makes any connection to a listed domain, it already knows to use HTTPS. No HTTP request is ever sent, not even on the first visit.

The list is compiled by Google and distributed to all major browser vendors. It contains hundreds of thousands of domains ranging from small personal sites to major financial institutions.

HSTS vs HSTS Preload: Key Differences

Feature	HSTS	HSTS Preload
First visit protection	No — first request may be HTTP	Yes — HTTPS enforced before any connection
How it works	Header sent by server; cached by browser	Domain list embedded in browser binary
Scope	Per browser, per user, after first visit	All users, all browsers, from day one
Removal	Expires when max-age elapses	Slow — requires months for browser updates to reach users

Requirements to Get on the HSTS Preload List

Before submitting your domain to hstspreload.org, your site must meet all of the following requirements:

Serve a valid, trusted TLS certificate on the domain and all subdomains.
Redirect all HTTP traffic to HTTPS — both the apex domain and the www subdomain.
Serve the HSTS header on the HTTPS response for the apex domain with:
- max-age of at least 31536000 seconds (1 year).
- The includeSubDomains directive.
- The preload directive.

http

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

includeSubDomains is mandatoryThe preload list requirement for includeSubDomains means every subdomain of your domain must support HTTPS. If any subdomain — including development or staging environments — does not have a valid certificate, users will see an HSTS error when visiting it and cannot bypass the warning.

How to Submit Your Domain

Once your HSTS header meets the requirements, submit your domain at hstspreload.org. The site checks your configuration automatically and flags any issues. After submission:

Your domain enters a pending queue.
It is included in the next Chromium source code commit containing preload list updates.
When a new Chrome version ships with the updated list, all Chrome users receive the protection.
Other browsers pull the same list and update on their own release schedules.

The process from submission to full browser distribution typically takes one to several months.

Verifying Your HSTS Configuration

Before submitting, verify your HSTS header is correctly served using the HSTS Checker tool. It confirms the header is present, checks the max-age value, and verifies the includeSubDomains and preload directives are included.

bash

# Check HSTS header on your domain
curl -I https://example.com | grep -i strict-transport-security

# Expected output:
# strict-transport-security: max-age=31536000; includeSubDomains; preload

The Removal Problem

Being on the preload list is easy to get into but difficult to leave. If you later need to serve content over HTTP (for example, if you create a subdomain without HTTPS support), you will need to request removal from the list. The removal process works like this:

Submit a removal request at hstspreload.org/removal.
Your domain is marked for removal in the next list update, which is shipped in a new browser release.
Users running the updated browser version will no longer have the preloaded policy.
Users on older browser versions remain protected for months or years until they update.

Removal is not instantEven after a removal request is approved and included in a browser release, existing users on older versions continue to enforce HTTPS for your domain. Full removal from all browsers in the wild can take a year or more.

Who Should Use HSTS Preload?

HSTS Preload is appropriate for domains where HTTPS is a permanent, long-term commitment and every subdomain either supports HTTPS or will never serve web content. It is particularly valuable for:

Financial services and banking sites.
Healthcare and sensitive data platforms.
Government and regulatory sites.
Any site handling user credentials or personal data.

It may be premature for domains with many subdomains in active development, domains that may need HTTP access in the future, or domains where TLS management is not fully centralised.

Frequently Asked Questions

Is HSTS Preload the same as HSTS?

No. HSTS is a server-sent header that browsers cache after the first HTTPS visit. HSTS Preload is a list of domains baked into browsers before any connection is made. Preloading provides protection from the very first visit, eliminating the first-use vulnerability of standard HSTS.

Do I need to renew my preload submission?

No. Once accepted, your domain stays on the list indefinitely. There is no expiry — you only need to take action if you want to be removed, which requires a formal removal request and takes a long time to fully propagate.

Will HSTS Preload affect HTTP-only subdomains?

Yes — because includeSubDomains is required. If any subdomain of your domain does not serve HTTPS with a valid certificate, browsers will block access to it and users will see an HSTS error they cannot bypass. Ensure all subdomains support HTTPS before submitting.

Can I add the preload directive without submitting to the list?

Yes. Adding preload to your HSTS header is harmless if you do not submit to hstspreload.org — it simply signals that you are ready to be added. Only domains that are actively submitted and accepted appear in the browser list.

How do I check if my domain is already on the preload list?

Visit hstspreload.org and enter your domain. It will show whether your domain is pending, actively preloaded, or not on the list. You can also use the HSTS Checker tool to inspect your current header and preload status.