HSTS Preload List - Data Source

Website	https://hstspreload.org/
Category	Browser Security & Hardware

The HSTS Preload List is a built-in browser security feature maintained by the Chromium project. It contains domains that have opted in to enforce HTTPS-only connections at the browser level, before any network request is made. This eliminates the window of vulnerability that exists with standard HSTS headers, where the first visit to a site could still occur over plain HTTP.

Source:HSTS Preload List

What is the HSTS Preload List?

HTTP Strict Transport Security (HSTS) is a web security mechanism that tells browsers to only connect to a site using HTTPS. Normally, a browser learns about a site's HSTS policy by receiving the Strict-Transport-Security header on its first visit. The HSTS Preload List goes further: domains on this list are hardcoded directly into browser source code, so the browser knows to use HTTPS from the very first connection, even if the user has never visited the site before.

The list is maintained by Google as part of the Chromium project and is shared across all major browsers including Chrome, Firefox, Safari, and Edge. Domain owners must explicitly submit their domains at hstspreload.org and meet strict requirements: the domain must serve a valid HTTPS certificate, redirect all HTTP traffic to HTTPS, serve the HSTS header on the base domain with a max-age of at least one year, and include the includeSubDomains and preload directives.

Inclusion on the preload list is a serious commitment. Because the list is shipped with browser binaries, removal takes months to propagate through browser release cycles. Domains that cannot guarantee HTTPS availability across all subdomains should not apply.

How We Use This Data

We display HSTS preload status on domain lookup pages across our sites. When you look up a domain on robtex.com or dns.ninja, we show whether it appears on the HSTS Preload List. This serves as a quick indicator of a domain's security posture: preloaded domains have made a strong, verified commitment to HTTPS-only communication.

This information is particularly useful for security assessments, as HSTS preload status signals that a domain operator has gone beyond basic HTTPS deployment to enforce encrypted connections at the browser level. It also helps identify domains where man-in-the-middle attacks via SSL stripping are effectively mitigated.

FAQ

What is the difference between HSTS headers and HSTS preloading?

Standard HSTS uses an HTTP response header (Strict-Transport-Security) to tell browsers to use HTTPS on future visits. However, the very first visit can still happen over HTTP, creating a brief vulnerability window. HSTS preloading eliminates this by hardcoding the HTTPS requirement into the browser itself, so even the first connection is forced to use HTTPS. Preloading requires meeting stricter criteria and is much harder to reverse.

Can any domain be added to the HSTS Preload List?

Any domain owner can submit their domain, but it must meet strict requirements: a valid TLS certificate, HTTP-to-HTTPS redirect on the base domain, an HSTS header with max-age of at least 31536000 seconds (one year), and the includeSubDomains and preload directives. All subdomains must also support HTTPS. Submissions are reviewed by the Chromium team before inclusion.

Why would a domain NOT want to be on the preload list?

Preloading is difficult to undo. If any subdomain cannot serve HTTPS (for example, legacy internal systems or hardware management interfaces), preloading will break access to those subdomains in all browsers. Removal from the list requires a submission and then waiting for all major browsers to ship an update containing the removal, which can take many months.