HSTS Header Test

Ensure HSTS is enabled site-wide so browsers always use HTTPS—shut the door on protocol downgrades and insecure requests.

Add Test Criteria

HSTS Header

Quick Summary

An HSTS Header Test checks whether your website sends the "Strict-Transport-Security" header and whether it’s configured properly.

  1. HSTS (HTTP Strict Transport Security) tells browsers to only use HTTPS for the domain for a specified period.
  2. It helps prevent SSL stripping and downgrade attacks by blocking HTTP access once the policy is cached in the browser.
  3. A strong policy typically includes "max-age", "includeSubDomains" and "preload".
  4. Misconfigured HSTS can break subdomains or lock users into HTTPS when your TLS setup isn’t ready.
  5. This tool helps you confirm your HSTS header exists, is correctly formatted, and whether it follows best practices.

What Is HSTS and How Does the Strict Transport Security Header Work?

HSTS stands for - HTTP Strict Transport Security. It is a browser security mechanism that ensures your website is accessed only over HTTPS.

HSTS is enabled by sending a response header called "Strict-Transport-Security" from your web server that is hosting the website. When a browser receives this header over a secure HTTPS connection, it remembers that your site should never be accessed using HTTP again for a specified period of time.

Once the policy is stored in the browser, the following things will happen:

  1. Any attempt to access the site using "http://"" is automatically upgraded to "https://".
  2. The browser refuses to make insecure HTTP connections to your domain.
  3. The risk of SSL stripping and downgrade attacks is significantly reduced.

This behavior is especially important because it protects users in the following situations:

  1. They manually type http:// in the address bar to access your website.
  2. They click on outdated or insecure HTTP links which could be added to other parts of your website or through social media links.
  3. An attacker attempts to intercept traffic and force an insecure connection.

The "Strict Transport Security header" works on a time-based policy. The duration is controlled by the "max-age" directive, which tells the browser how long (in seconds) it should enforce HTTPS-only access. During this period, the browser will not attempt an HTTP connection to your website.

In short, HSTS shifts HTTPS enforcement from the server to the browser itself. This makes HTTPS usage more reliable, consistent, and resistant to network-based attacks especially on public or untrusted networks.

Key HSTS Directives

The Strict Transport Security header is made up of directives that control how browsers enforce HTTPS for your domain. The most common directives are max-age, includeSubDomains, and preload.

max-age

max-age sets how long in seconds the browser should enforce HTTPS-only access for your website.

  1. max-age=31536000 = 1 year
  2. max-age=63072000 = 2 years

During this time, the browser will automatically upgrade HTTP requests to HTTPS and refuse insecure connections.

includeSubDomains

includeSubDomains extends the HSTS rule to all subdomains (for example: blog.example.com, app.example.com).

Important: Only enable this if every subdomain you use is HTTPS ready. Otherwise, you can accidentally break services that are running on HTTP.

preload

preload is an optional directive used when you want to be eligible for the "HSTS preload list" (a list built into many browsers).

If your domain is preloaded, browsers will enforce HTTPS even on the first visit, before they’ve ever seen your header.

Note: Adding preload alone does not automatically preload your site. You must also meet preload requirements and submit your domain for inclusion.

FAQs on HSTS Header Test

The HSTS header is called Strict-Transport-Security. When a browser receives it over HTTPS, it remembers to access your site only via HTTPS for the duration you specify.

Not exactly. Your server can redirect HTTP to HTTPS, but HSTS makes the browser automatically upgrade requests to HTTPS after it has stored the policy. This provides stronger protection than redirects alone.

Many sites use 1 year (31536000) or 2 years (63072000) once they are confident HTTPS is stable. A safer approach is to start with a short max-age and increase it gradually.

Only if every subdomain you use is HTTPS-ready. If a subdomain still runs on HTTP, enabling includeSubDomains can break access to that subdomain until the policy expires.

Preload is an optional directive used when you want to be eligible for the HSTS preload list. If your domain is preloaded, browsers enforce HTTPS from the very first visit, even before they’ve seen your header.

No. Adding preload does not automatically preload your site. You must meet the preload requirements and submit your domain for inclusion in the preload list.

Yes. If your certificate expires, HTTPS breaks, or a subdomain is not HTTPS-ready, users may be unable to access those endpoints until the HSTS max-age expires. That’s why a staged rollout is recommended.

Run it after enabling HTTPS, after changing hosting/CDN settings, after renewing or switching certificates, and periodically to ensure the header is still present and configured correctly.

If you ain’t measuring it,
you aren’t improving it.

Free Signup