HSTS Preload Header Validator & Generator
Generate and validate HTTP Strict Transport Security (HSTS) headers and server configs for Chrome and Firefox preload list eligibility.
HSTS Policy Parameters
Clean host parsed: example.com
Validated Output & Configuration
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Serve a Valid TLS/SSL Certificate
Domain must resolve over HTTPS with a trusted, unexpired CA certificate.
Enforce Permanent Redirect to HTTPS (Port 80 to 443)
HTTP requests must redirect with a 301/308 status to the same host on HTTPS.
Serve HSTS on the Root Apex Domain
Must be served directly on the base domain (example.com), not only on www.
Specify Minimum max-age of 1 Year (31,536,000s)
Current value: 31,536,000s (365.0 days). Minimum required is 31,536,000s.
Include 'includeSubDomains' Directive
All subdomains (API, mail, intranet, staging) must support HTTPS without exceptions.
Include 'preload' Directive
Explicit authorization granting browser vendors permission to hardcode the domain.
# Add inside your HTTPS server { ... } block:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;100% Client-Side In-Memory Execution: All policy generation, regex host sanitization, and server directive builds execute exclusively inside your web browser. No domain names, internal infrastructure topologies, or security configurations are ever transmitted to or stored on external servers.
HTTP Strict Transport Security (HSTS): Mitigating Man-In-The-Middle Attacks
HTTP Strict Transport Security (RFC 6797) was engineered to close a fundamental security flaw in how the Internet transitions connections from insecure plaintext HTTP to encrypted HTTPS. By default, when a user types domain.com into a web browser, the client issues an initial unencrypted HTTP request over Port 80 before receiving a 301/302 redirect instructing it to establish a TLS handshake on Port 443.
During that initial unencrypted roundtrip, attackers operating on open Wi-Fi networks, local gateways, or compromised routers can intercept the traffic using tools like SSLstrip. The adversary impersonates the web server, proxying requests over plain HTTP while communicating with the legitimate server over HTTPS. Before configuring strict transport policies, verify your domain's active TLS trust chain and certificate expiration using our live SSL certificate checker to prevent locking out visitors due to incomplete intermediate authority bundles.
Client-Side HTTPS Upgrade
Once cached by a browser, all internal URLs and user inputs targeting http:// are automatically rewritten to https:// before any packet touches the network card.
Non-Bypassable Warnings
HSTS disallows users from clicking through self-signed certificate errors, expired TLS certs, or hostname mismatches, preventing social-engineering certificate interception.
Preload Engine Immunity
Through the Chromium HSTS Preload list, the browser hardcodes your HTTPS-only requirement into its compiled binary, eliminating even the very first unencrypted connection window.
Anatomy of the Strict-Transport-Security Header
| Directive | Requirement | Recommended Value | Architectural Impact |
|---|---|---|---|
| max-age=<seconds> | Mandatory | 31536000 (1 Year) | Defines the duration in seconds that the browser must remember to enforce HTTPS exclusively. |
| includeSubDomains | Optional (Preload Req.) | Present | Applies the HTTPS-only rule recursively across all existing and future subdomains (mail, staging, api). |
| preload | Optional (Preload Req.) | Present | Explicitly authorizes browser vendors to burn the domain into browser binaries for hardcoded TLS enforcement. |
Zero-Downtime Phased Rollout Protocol
Prematurely issuing an HSTS header with a one-year duration and includeSubDomains without auditing child infrastructure can break internal services, private VPN portals, or legacy mail endpoints. In parallel with transport-layer hardening, webmasters should deploy our RFC 9116 security.txt generator to establish clear, direct reporting channels for external researchers who encounter certificate or header misconfigurations during rollout.
max-age=300 (5 Min)
Verify that apex HTTP traffic redirects cleanly to HTTPS without certificate chain errors or redirect loops.
max-age=86400 (1 Day)
Monitor customer traffic for mixed-content warnings or broken assets across production pages.
includeSubDomains
Expand scope to subdomains with a 1-week duration (604800). Ensure all internal hostnames have automated SSL renewals.
max-age=31536000; preload
Commit to full preloading by setting 1 year TTL and submitting the apex host to hstspreload.org.
Frequently Asked Questions (FAQ)
What is HTTP Strict Transport Security (HSTS)?
HTTP Strict Transport Security (HSTS) is an IETF-standardized response header (RFC 6797) that instructs web browsers to only communicate with a domain over encrypted HTTPS connections. Once received, the browser automatically transforms all plain HTTP requests to HTTPS on the client side before network transmission, preventing SSL stripping and downgrade attacks.
What is the HSTS Preload List?
The HSTS Preload List is a hardcoded database maintained by Google Chrome and adopted by Firefox, Apple Safari, Microsoft Edge, and Opera. Domains on this list are permanently accessed via HTTPS from the very first connection attempt, closing the vulnerability window that exists before a client first receives an HSTS header.
What are the strict requirements to qualify for HSTS Preload?
To be eligible for HSTS Preloading, you must serve a valid TLS certificate, redirect all HTTP traffic to HTTPS on port 443, serve the header on the apex/root domain, specify a max-age of at least 31536000 seconds (1 year), include the includeSubDomains directive, and include the preload directive.
What risks are associated with the includeSubDomains directive?
When includeSubDomains is declared, every subdomain—including internal testing servers, private intranet tools, legacy legacy APIs, and mail portals—must support valid HTTPS. If any subdomain lacks a valid SSL certificate, users will experience non-bypassable connection lockouts.
How do I safely roll out HSTS to avoid service interruptions?
Adopt a phased staging deployment: Begin with a short max-age such as 300 seconds (5 minutes), observe network metrics and mixed-content logs, step up to 86400 seconds (1 day), then 2592000 seconds (1 month). Only add includeSubDomains and preload with max-age=31536000 once you verify that all child services have valid TLS certificates.
How do I remove a domain from the HSTS Preload List if issues arise?
Removal requires submitting a removal request at hstspreload.org. However, removal is not instant: it takes weeks or months for updated browser releases to cycle through user devices across Google Chrome, Safari, and Firefox. Preloading should be treated as a permanent architecture commitment.
Related & Complementary Utilities
Explore more privacy-first client-side web tools.
IP Location Lookup & GeoIP Visualizer
Inspect IPv4/IPv6 locations, ASN telemetry, ISP network data, and interactive location maps.
Security.txt RFC-9116 Policy Document Builder
Generate RFC 9116 compliant security.txt policy documents with live validation, PGP key integration, and CSAF endpoints.
CAA DNS Record Synthesizer
Synthesize RFC 8659-compliant Certificate Authority Authorization (CAA) DNS records with wildcard security controls and iodef alerts.
IPv6 to IPv4 & Hexadecimal Address Expander
Enterprise-grade IPv6 address expander, RFC 5952 compressor, IPv4-mapped address extractor, 128-bit binary visualizer, and ip6.arpa reverse DNS PTR generator.