HTTP Strict Transport Security, or HSTS, tells a browser to use HTTPS for future visits to a domain. A website sends a Strict-Transport-Security response header over a valid HTTPS connection. The browser stores that policy and upgrades later HTTP URLs before sending a request. The browser applies HSTS before contacting the server, so no HTTP redirect is needed for those upgraded requests.

Preloading addresses the first visit, when a browser has not yet received the site's HSTS header. A browser can ship with a list of domains to treat as HTTPS-only from the start. Preloading can affect every subdomain and cannot be disabled quickly for browsers that already have the list. Maintaining HTTPS across that entire group of hosts is therefore a long-term requirement.

How Browsers Learn an HSTS Policy

Without an applicable cached or preloaded HSTS rule, a browser may send an HTTP request and receive a redirect to HTTPS. The browser can then learn a policy from the HSTS header in a valid HTTPS response. A header sent over plain HTTP is ignored because an attacker on the network could alter it. Once the browser has stored the policy, later HTTP URLs for that host are changed to HTTPS before a request is sent, including during the same visit.

Once a browser enforces HSTS for a host, it also refuses to let the user click through certificate errors for that host. If the certificate is invalid or HTTPS is unavailable, the browser blocks the connection instead of allowing an insecure fallback. An HTTP redirect works differently: a browser that actually sends an HTTP request receives a response telling it where to go. A site may use both redirects and HSTS, but one does not replace the other.

Understand Max-Age and Subdomain Scope

The max-age directive states in seconds how long a browser should remember the host's HTTPS-only policy. Each valid HTTPS response carrying the header sets the expiration to the current time plus the supplied duration. Removing the header later does not instantly erase a policy already stored by visitors. The cached policy remains active until its stored expiration time unless a valid HTTPS response sets max-age=0 for that host.

The optional includeSubDomains directive extends a parent domain's policy to every descendant hostname. If example.com sets it, shop.example.com and deeper descendants are covered after the browser learns the parent policy. Internal and rarely used subdomains are included too, so check whether those hosts support HTTPS before enabling the directive. A policy set by secure.example.com does not extend upward to example.com.

Browsers can store HSTS policies for a parent and a subdomain independently. Clearing the parent entry does not erase a separate policy learned from the subdomain. For example, a browser may have separate expiration times for example.com and shop.example.com. HSTS policies apply to domain names, not literal IP addresses.

What a Preload List Changes

A browser preload list supplies an HTTPS-only rule before the browser's first request to a listed domain. Chrome includes such a list, and other major browsers maintain related lists. If the installed list covers the domain, the browser upgrades an HTTP URL even when that browser has never visited the site. Inclusion is tied to the browser's installed list, so submitting a domain does not immediately change the behavior of every browser.

New submissions to Chrome's preload list require a valid certificate, HTTPS on all subdomains, and an HTTP-to-HTTPS redirect on the same host if port 80 is open. The base domain must send an HSTS header with max-age of at least 31536000 seconds, or one year, plus includeSubDomains and preload. An HTTPS redirect from the base domain must carry that header too. The preload flag signals consent to submission; adding the flag alone does not add a domain to the list.

HSTS is recommended for sites committed to HTTPS, but new preloading is not generally recommended. Many browsers already try HTTPS first, so the additional protection must be weighed against maintaining HTTPS on every subdomain and waiting for list removal. Treat preloading as a separate, deliberate choice rather than a default HSTS setting.

Plan for Rollback Limits

For a non-preloaded domain, an operator can send max-age=0 on a valid HTTPS response to clear that host's stored policy when the browser receives it. Merely deleting the header leaves previous browser state until expiration. If a parent's policy covers a subdomain, a header from that subdomain cannot cancel the inherited rule. The parent policy must be changed, and any separate policy learned from the subdomain must also be cleared or allowed to expire. If HTTPS is already broken, affected browsers may be unable to receive a valid response that clears the policy.

Preload removal is slower. Removal can take months to reach Chrome users through updates, and other browsers may follow different schedules. Removing preload from a response header does not immediately remove the domain from installed lists. Keep HTTPS working on the domain and its subdomains while browsers may still enforce the old entry.

Test Deployment in Stages

Before a broad HSTS policy, verify valid HTTPS for the parent and every intended subdomain, including less visible administrative and internal names. Check redirects separately, and confirm the HSTS header is returned only over HTTPS with the intended directives. Start with a short max-age, monitor for broken pages, and fix problems before increasing the duration. Wait through the full current duration before moving to the next stage.

Compare a fresh browser profile with one that has already learned the policy. A fresh profile may still enforce a preload entry, so distinguish the built-in list from policy learned during browsing. Record which hosts are covered and how their HTTPS service will be maintained during a change of hosting provider or certificate. A successful test of the public homepage alone does not confirm that a rarely used internal subdomain will remain reachable.