HSTS Preload (HSTS preload list)

The HSTS preload list is maintained by the Chromium project, and submissions go through hstspreload.org; Chrome, Firefox, Safari and Edge all ship lists derived from it. A preloaded domain, together with all its subdomains, is hard-coded into the browser, so the browser never makes a plaintext HTTP request to it, even on a fresh install. Whole top-level domains can be preloaded too: .app and .dev are examples, which is why sites on them must use HTTPS from day one.

Why it matters

Ordinary HSTS relies on the browser having seen the header before, which leaves the first visit open to SSL stripping. Preloading closes that gap, but the commitment is heavy. Only the registrable domain (example.com, not www.example.com) can be submitted, and it must have a valid certificate, redirect HTTP to HTTPS on the same host, and send an HSTS header with includeSubDomains, preload and a max-age of at least one year (31536000 seconds). Every subdomain that a browser might visit, including intranet tools, must then work over HTTPS. Removal is possible but slow: it ships with browser releases, and older browser versions keep the entry.

Example

The header a preload candidate must return on https://example.com:

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

Before submitting, inspect what the apex domain actually returns with the HSTS checker and list every subdomain in use.

Common misconceptions

• Adding preload to the header puts you on the list. The directive only signals consent; the domain must be submitted, accepted and then shipped in browser releases.
• Preloading can be undone quickly. Removal takes a browser release cycle to reach users, and outdated browsers keep the entry for good, so treat it as permanent.
• Only the main website is affected. includeSubDomains applies to every subdomain, so an HTTP-only admin page or device interface under the domain becomes unreachable in browsers.