HSTS Preload: What It Is and How to Enable It
A practical guide to HTTP Strict Transport Security, the HSTS preload list, and the header settings you need before asking browsers to hard-code HTTPS for your domain.
What HSTS does
HTTP Strict Transport Security, usually shortened to HSTS, is a response header that tells browsers to use HTTPS for future visits to your domain. Once a browser has seen a valid HSTS policy, it should stop trying plain HTTP for that site during the policy window. That reduces downgrade risk and removes one of the easiest ways users end up on an insecure URL by mistake.
HSTS is useful because redirects alone only help after the browser has already made an HTTP request. With a strong HSTS policy, repeat visitors can skip that insecure first hop. It is not a substitute for a valid certificate or a correct redirect configuration, but it is an important layer in a mature HTTPS deployment.
What preload adds
The HSTS preload list goes a step further. Instead of waiting for a browser to learn your HSTS policy from a prior visit, major browsers can ship your domain as HTTPS-only from the start. That means even a first-time visitor is directed to HTTPS immediately, which strengthens the protection against accidental insecure requests and some downgrade scenarios.
Preload has real benefits, but it is intentionally strict. You are asking browsers to hard-code expectations for your domain, so you need confidence that every important hostname is ready. If your subdomains are inconsistent, or your team still depends on HTTP anywhere, preload can create breakage instead of security. The upside is strong, but only if the groundwork is already solid.
How to enable HSTS safely
Start by making sure your site always redirects HTTP to HTTPS and that the certificate is healthy on every hostname you care about. Then send an HSTS header such as `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload` from the HTTPS response. The exact policy should match your environment, but preload readiness typically requires a long `max-age`, HTTPS on the base domain, and support across subdomains.
Roll HSTS out carefully if you have legacy systems. A short test policy can help you confirm nothing depends on HTTP anymore. Once you are confident, increase the `max-age` and only pursue preload when the whole domain family is ready. The hard part is not adding the header itself. The hard part is proving that your infrastructure can live with that promise long term.
How to verify your header and preload readiness
Do not assume the header is live just because you changed a config file. CDNs, reverse proxies, and app servers can each modify or strip headers. Always verify the actual response that visitors receive. You want to confirm the HSTS header is present, the directive values are what you intended, and the broader HTTPS setup does not undermine the policy.
Https Co checks live response headers, so it is a fast way to confirm whether HTTP Strict Transport Security is present before you think about preload submission. Use the tool after each change, especially if you manage multiple layers of infrastructure. The goal is simple: enable HSTS deliberately, verify it externally, and only then consider the preload list.
Verify your HSTS header before you preload
Run the checker to confirm your live header response, HTTPS redirects, and certificate health before you rely on HSTS or submit a domain for preload.