HSTS Preload: Requirements and Risks Before You Submit

What the HSTS preload list is

An HSTS header tells the browser to reach a domain only over HTTPS for the duration of max-age. The weakness lies in the first contact: HSTS does not take effect until the browser has made at least one secure connection and received the header (MDN). Until then, an attacker on the same network can intercept the first unencrypted request. RFC 6797 describes a countermeasure in the form of a list that browsers ship with, similar to the root certificates of certification authorities (RFC 6797).

This list is maintained for Chrome and built into the browser. Requests to listed domains are made only over HTTPS; any HTTP request is upgraded and fails to connect if HTTPS is unavailable (hstspreload.org). Firefox, Safari and Edge keep their own preload lists based on the Chrome list (hstspreload.org). The list is not part of the HSTS specification, and MDN notes that it should not be treated as official (MDN).

Keep the directive and the entry apart. The specification does not know preload; RFC 6797 does not define the directive (RFC 6797). It is addressed to the list maintainers: a site that sends it is considered to be requesting inclusion, and the domain may be submitted through the form on hstspreload.org (hstspreload.org). A domain is protected only once it is actually on the list and that list has reached the user with an update. New entries are hardcoded into the Chrome source code and can take several months to reach the stable version (hstspreload.org).

The HTTP Archive's Web Almanac shows how widespread the directive is: 36 percent of pages visited on mobile send an HSTS header (Web Almanac 2025). Of the sites with HSTS, roughly 40 percent set includeSubDomains and about 22 percent set the preload directive (Web Almanac 2025). The figure does not reveal how many of them were actually submitted. It does show how often preload is served; whether each instance reflects a deliberate decision cannot be seen from the outside.

Why the added benefit has shrunk

The preload list was created for a problem that browsers now tackle in other ways too. Many browsers, including Chrome and Safari, automatically upgrade HTTP navigations to HTTPS regardless of a domain's HSTS policy. According to hstspreload.org, preloading only adds protection when these upgrades fail in the presence of an active attacker (hstspreload.org).

For Chrome, Google announced in October 2025 that Chrome 154 would enable the “Always Use Secure Connections” setting by default, planned for October 2026 (Google Security Blog). Chrome is then meant to ask before the first visit to a public site without HTTPS. We have covered separately what the Chrome HTTPS requirement means for websites. The difference from HSTS lies in the way out: in this mode, Chrome shows a warning that can be bypassed when HTTPS is unavailable (Google Security Blog).

An HSTS domain has no such way out. If a TLS error occurs while connecting, such as an invalid certificate, the browser offers no way to proceed past the error message (MDN). RFC 6797 calls this “no user recourse”: a site that issues an HSTS policy opts into terminating the connection on every certificate error (RFC 6797). With a preload entry, that applies to every visitor, even on the very first visit, and to every subdomain.

That strictness is at the heart of the trade-off. HTTPS-First protects most first visits and leaves a way out when something goes wrong. A preload entry additionally protects against an attacker who actively blocks the upgrade, but it takes the way out away from every visitor as soon as any subdomain lacks a valid certificate. For domains under heavy attack pressure with fully controlled infrastructure, that can be worth it. For a company domain that also carries the intranet, device logins and old campaign sites, the risk usually outweighs the gain.

Requirements for inclusion

The conditions are listed on hstspreload.org under “Submission Requirements”. They are short, but they reach well beyond the home page:

• Valid certificate for the domain (hstspreload.org).
• Redirect from HTTP to HTTPS on the same host if the server listens on port 80 (hstspreload.org). So http://example.com must first point to https://example.com, not straight to https://www.example.com.
• All subdomains over HTTPS, in particular www if a DNS record exists for it (hstspreload.org).
• HSTS header on the base domain with a max-age of at least 31,536,000 seconds, i.e. one year, plus includeSubDomains and preload (hstspreload.org).
• Header on intermediate redirects too: if the HTTPS site redirects again, for example to www, that redirect must already carry the header, not just the target page (hstspreload.org).

The example on hstspreload.org uses max-age=63072000, i.e. two years (hstspreload.org). One year is the minimum, not a target. Across the web, the median of valid max-age values is exactly one year according to the Web Almanac 2025 (Web Almanac 2025). A single query shows whether your redirect chain meets the “same host first” condition; you will find it below with the stages.

Two details fail more often in practice than the values themselves. First, only the first HSTS line of a response counts: if a browser receives several, it processes only the first (RFC 6797). If the application and an upstream proxy each set their own line, the browser may apply a different policy from the one you checked, and the hstspreload.org check treats multiple HSTS lines as an error (chromium/hstspreload). Second, the header belongs only in HTTPS responses; received over HTTP, the browser must ignore it (RFC 6797). The HTTP header inspector shows which headers are actually served.

# HTTP: redirect only, no HSTS header
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

# HTTPS: exactly one HSTS line, also on redirects and error pages
server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=2592000; includeSubDomains" always;
    # add preload only after a deliberate decision
}

Inventory subdomains before the entry covers them

The most consequential sentence of the requirements sits in a note below them: preloading applies to all subdomains, including internal subdomains that are not publicly accessible (hstspreload.org). When submitting, the operator confirms that all subdomains and nested subdomains, i.e. .example.com and .*.example.com, can no longer be accessed without a valid HTTPS certificate (hstspreload.org). That includes a name like printer.office.example.com that only resolves on the company network.

The inventory therefore belongs before the submission. No single source is complete, so it pays to combine several:

Two technical details make the inventory stricter than it first seems. HSTS applies to all ports of the host, regardless of the port used for the request (MDN). A service that speaks only HTTP on internal.example.com:8080 is affected just like the website. And RFC 6797 explicitly describes services that deliberately run over HTTP, such as a certification authority's revocation lists and OCSP on a subdomain: if the parent domain sets includeSubDomains, browsers can no longer retrieve them (RFC 6797).

Raise max-age in stages

hstspreload.org recommends not setting max-age to one year right away but ramping it up in stages, each already with includeSubDomains (hstspreload.org). Before that comes a step that is easy to skip: check that all subdomains and nested subdomains work properly over HTTPS, explicitly including internal ones (hstspreload.org).

1. 5 minutes: max-age=300; includeSubDomains
2. 1 week: max-age=604800; includeSubDomains
3. 1 month: max-age=2592000; includeSubDomains
4. Then: at least one year with includeSubDomains; add preload only once the decision to submit has been made.

During each stage, watch for broken pages and monitor the site's metrics such as traffic and revenue, fix any problems and then wait out the full max-age of the stage, so a month in the last stage (hstspreload.org). The point: a faulty policy stays stored in visitors' browsers only as long as max-age allows. A mistake in the first stage is forgotten within minutes, a mistake with a one-year lifetime is not.

Important for the way back: max-age=0 ends HSTS in the browser, including includeSubDomains (RFC 6797). It only works for browsers that reach the domain over HTTPS again afterwards, because HSTS cannot be disabled over insecure HTTP (MDN). For the preload list, max-age=0 does not replace a removal request; more on that below. The quickest way to check each stage is the command line:

The first query counts the HSTS lines; more than one is a finding. The second shows the value the browser adopts. The third checks whether the HTTP redirect stays on the same host. For subdomains, the same query belongs in a loop over the inventory list.

The submission and what follows

Submissions go through the form on hstspreload.org. It checks the requirements and, if they are met, reports that the domain is pending inclusion. From then on, the domain must keep meeting the requirements, or it will be removed (hstspreload.org). Removing preload from the header later makes the domain immediately eligible for removal, and domains that stop meeting the requirements may be removed automatically in the future (hstspreload.org).

The free SSL check shows your domain's current state. If the domain sends an HSTS header, it evaluates the header and queries the list status at hstspreload.org, for example “listed”, “submission pending”, “removal pending” or “not listed”. If the query could not be answered, it shows “not determined” rather than a guessed status.

For planning, Chrome's release cycle is worth a look. A new major version reaches the stable channel every two weeks (Chromium). Enterprises using the extended stable channel get a new major version only every eight weeks (Chromium). An entry that travels into the browser through the source code therefore does not reach every user the next day. The same applies to a removal, just in the opposite direction.

Removal: the long way back

hstspreload.org opens its removal section with a clear sentence: inclusion in the preload list cannot easily be undone (hstspreload.org). Domains can be removed, but it takes months for a change to reach users with a Chrome update, and there is no commitment for other browsers (hstspreload.org).

The removal page is more specific: a removal may take 6 to 12 weeks to reach most Chrome users and may take longer for other browsers (hstspreload.org). Only a domain that keeps serving HTTPS with a valid certificate and a valid HSTS header without preload can request it through the removal form (hstspreload.org). Anyone trying to solve a problem by switching off HTTPS on the main domain also blocks this route to removal.

The real damage happens in the meantime: every subdomain without a valid certificate stays blocked for visitors with a current browser until the removal has reached them. hstspreload.org states that it will generally honor removal requests if a subdomain cannot be served over HTTPS for strong technical or cost reasons (hstspreload.org). The reverse route is usually faster than removal: give the affected subdomain a certificate. The article on ACME renewal shows how to issue certificates automatically and test the renewal.

Submit, wait or skip

In the end there is a trade-off that a few questions can structure. A submission is worth considering if all of the following apply:

• The domain and all current subdomains serve HTTPS with a valid certificate, internally and externally.
• New subdomains are created only through a process that includes HTTPS from the start.
• No third-party services run under the domain whose HTTPS you do not control.
• The stages up to one year of max-age have been completed without findings.
• A person or team is permanently responsible and knows that the way back takes months.

You should rather skip it if the domain also carries the company network, devices and partner services, if an agency looks after the website but not the DNS and internal IT, or if nobody can say which subdomains exist. An HSTS header with includeSubDomains and a one-year lifetime delivers the larger part of the benefit without the fixed commitment (hstspreload.org), because a mistake there can be caught again through max-age and new responses. The subdomain inventory is still needed: includeSubDomains affects every subdomain for returning visitors in the same way.

Keep the HSTS line under watch

Submitted or not, the HSTS line is configuration that can change with every server, proxy or CDN switch. The XICTRAQ® security scan evaluates it the way a browser applies it: only the first line counts, a line with a syntax error counts as ineffective, and max-age=0 is reported as the end of HSTS. A preload-ready line, meaning exactly one line with at least one year, includeSubDomains and preload, earns extra points in the score. If the server sends several HSTS lines, a warning appears noting that browsers apply only the first and hstspreload.org rejects multiple.

The bonus rates the line, not the entry. XICTRAQ® does not add a domain to the list or remove it; the decision stays with you and follows the criteria above. A better score is no reason to submit. If the score drops below a minimum you set in the notification settings, you get an alert.

For the inventory, DNS and domain monitoring helps: XICTRAQ® can discover known subdomains via Certificate Transparency logs and suggest them for monitoring, and each subdomain can be monitored as a separate website within your plan's website limit. That way a certificate problem on a subdomain shows up before visitors report it. To make sure such an alert does not go unread at night, it pays to test your alerting chain regularly.

Preload is a commitment for years

An entry on the HSTS preload list is quick to request and takes weeks to months to disappear again. If you are considering it, keep to the order: first introduce HSTS cleanly, without preload, using the basics of security headers, eliminate mixed content and check your TLS configuration, then inventory all subdomains and raise max-age in stages. Only once every subdomain speaks HTTPS and someone is permanently responsible for it is preload a decision rather than a line from a template.