App StoreApp Store
Google PlayGoogle Play
Temp Mail Logo

Temp Mail safeguards your privacy while keeping your inbox free from spam.

🔐 max-age · includeSubDomains · preload · Preload List Status

HSTS Checker

Free HSTS checker. Verify any domain's HTTP Strict Transport Security header — check max-age, includeSubDomains, preload directive, and whether the domain is on the Chrome & Firefox HSTS preload list.

✓ HSTS header analysis✓ Preload list status✓ max-age check✓ A+ to F grade✓ No signup
HSTS Header Checker
Try:
🔐
Enter a domain above to check its HSTS configuration
What this tool does

Free HSTS checker — verify HTTP Strict Transport Security configuration and preload list status

How HSTS works, what each directive does, and how to achieve an A+ grade

This HSTS checker retrieves your domain's Strict-Transport-Security response header via the SSL Labs API (same trusted engine used by security professionals globally), then cross-references your domain against the official HSTS preload list via hstspreload.org. The result is a complete picture of your HSTS configuration, from basic header presence to preload list eligibility.

HSTS is a critical security mechanism that prevents the most common class of man-in-the-middle attacks: SSL stripping. Without HSTS, a network attacker can intercept the user's initial HTTP request and serve a fake HTTP version of your site, silently stripping the HTTPS upgrade. With HSTS, the browser refuses to make any HTTP request to your domain after it has seen the HSTS header once — converting all requests to HTTPS before they leave the browser.

A complete, secure HSTS configuration requires four things: the header must be present, max-age must be at least 31536000 (one year), includeSubDomains must be set (to protect all subdomains), and the preload directive should be present if you want the domain included in browser preload lists. This tool checks all four and explains exactly how to fix any gaps.

HSTS directives explained
max-age
The number of seconds browsers cache the HSTS policy. After receiving the header, the browser forces HTTPS for this duration. Minimum recommended: 31536000 (1 year). The preload list requires at least 31536000.
includeSubDomains
Extends the HSTS policy to all subdomains. Without this, subdomains like mail.example.com or api.example.com could still be accessed via HTTP. Required for preload list eligibility.
preload
Signals consent to include the domain in browser HSTS preload lists. Adding this directive is not enough alone — you must also submit via hstspreload.org. Once preloaded, browsers will always use HTTPS even on the first visit.
HTTPS Redirect
HSTS only works if your server redirects HTTP to HTTPS first. A missing or incorrect redirect (e.g. 302 instead of 301) can prevent HSTS from being set on the first visit.
Examples

HSTS configuration examples — from basic to preload-ready

Real HSTS header examples with explanations of what each configuration means
A+ Preload-readyComplete HSTS — max-age, includeSubDomains, preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Duration: 2 years (63072000 seconds) includeSubDomains ✓ all subdomains protected preload ✓ eligible for preload list submission Grade: A+

This is the gold-standard HSTS configuration. Two-year max-age, all subdomains covered, and preload-eligible. This header, combined with HTTP→HTTPS redirects on all subdomains, qualifies for submission to the Chrome, Firefox, and Edge HSTS preload lists. Once preloaded, the domain is protected from the very first browser visit.

Grade BBasic HSTS — correct but missing includeSubDomains and preload
Strict-Transport-Security: max-age=31536000 Duration: 1 year includeSubDomains ✗ missing — subdomains not protected preload ✗ missing — not eligible for preload list Grade: B Fix: add includeSubDomains; preload to the header value

A basic HSTS header with only max-age is a good start but leaves subdomains unprotected. Without includeSubDomains, an attacker can still target subdomains via HTTP. Adding includeSubDomains and preload (after verifying all subdomains serve HTTPS) upgrades this to a preload-eligible A+ configuration.

Grade FNo HSTS — domain serves HTTP without Strict-Transport-Security
HTTP/1.1 200 OK Content-Type: text/html ❌ Strict-Transport-Security: NOT SET Risk: SSL stripping attacks possible Risk: Cookie hijacking on shared networks Risk: Browser won't upgrade future HTTP requests Fix for Nginx: # Must be inside HTTPS (443) server block add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

A domain without HSTS is vulnerable to SSL stripping. On any untrusted network (coffee shop Wi-Fi, hotel internet), an attacker can intercept HTTP requests and prevent the HTTPS upgrade from ever happening. Adding the HSTS header to your server configuration is a one-line fix that dramatically improves security.

FAQ

Frequently asked questions about HSTS and HTTP Strict Transport Security

Common questions about HSTS configuration, the preload list, and HTTPS security
What is HSTS (HTTP Strict Transport Security)?
HSTS is a web security policy mechanism that forces browsers to only connect to a website over HTTPS — never HTTP — for a specified duration. Once a browser receives a valid HSTS header, it will automatically convert any HTTP request to HTTPS for the duration of the max-age period, and will refuse to connect at all if the HTTPS connection is insecure (e.g. invalid certificate). This protects against downgrade attacks and cookie hijacking.
What is the HSTS preload list?
The HSTS preload list is a hardcoded list of domains that major browsers (Chrome, Firefox, Safari, Edge) ship with, instructing them to always use HTTPS for those domains — even on the very first visit, before they've ever received an HSTS header. To qualify, your domain must already serve a valid HSTS header with max-age of at least 31536000, includeSubDomains, and the preload directive. You then submit via hstspreload.org. Once listed, removal takes 6–12 months to propagate.
What should my HSTS max-age be?
For production sites, use at least max-age=31536000 (1 year). To qualify for the HSTS preload list, this is the minimum — and it's generally the recommended starting point. More security-conscious deployments use max-age=63072000 (2 years). Avoid setting max-age below 86400 (1 day) — short max-ages provide minimal security benefit because attackers just need to wait for the cache to expire. Start with a short max-age only during initial HSTS rollout testing, then increase it once you're confident.
What does includeSubDomains do?
The includeSubDomains directive extends the HSTS policy to all subdomains of the domain that served the header. Without it, an attacker could create or compromise a subdomain (e.g. login.example.com) that serves HTTP, and use that to steal cookies set on the parent domain. includeSubDomains is required for HSTS preload list eligibility. Important: before enabling it, ensure all your subdomains (including ones used for email, testing, or APIs) already serve valid HTTPS — otherwise you'll break them.
What does the preload directive do?
Adding the preload directive to your HSTS header signals that you consent to your domain being included in browser HSTS preload lists. However, adding preload to your header alone is not enough — you also need to submit your domain at hstspreload.org and wait for it to be accepted and pushed in browser updates. Once preloaded, your domain will use HTTPS even on the very first visit from a browser that has never visited your site before.
What happens if I set HSTS and then my HTTPS breaks?
If your HTTPS certificate expires or your server is misconfigured after HSTS is active, users who have cached the HSTS policy will be completely unable to access your site via HTTP — the browser blocks the connection entirely. This is why HSTS should be rolled out carefully: start with a short max-age (e.g. 86400 = 1 day), ensure everything works correctly, then gradually increase it to 31536000. Never enable HSTS if your HTTPS setup isn't stable. For preloaded domains, the lock-in is even longer.
Does HSTS protect against man-in-the-middle attacks?
HSTS significantly reduces the risk of man-in-the-middle (MITM) attacks by preventing browsers from making unencrypted HTTP connections. Without HSTS, an attacker on the same network can intercept an initial HTTP request and redirect the user to a fake HTTPS site (SSL stripping). With HSTS, the browser refuses to make the initial HTTP connection at all — the request is converted to HTTPS before it leaves the browser. HSTS preloading extends this protection to the very first visit.
How do I add HSTS to my website?
For Nginx, add this inside your HTTPS server block: add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload' always; For Apache, add: Header always set Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload' For Cloudflare, enable HSTS in SSL/TLS → Edge Certificates → HTTP Strict Transport Security. For Next.js, add it in the headers() function in next.config.js. After adding the header, use this tool to verify it's correctly configured.
Related Security Tools

Need a disposable email address?Stop exposing your real inbox — get a free instant throwaway email with no signup and no trace.

Get Free Temp Mail →