Configure HTTP Strict Transport Security headers with preload eligibility checking and max-age recommendations.
The HSTS Header Builder turns a retention choice and scope flags into a Strict-Transport-Security response field, then evaluates that selection against preload-oriented requirements and max-age guidance. Choose how many seconds browsers should remember the policy, whether it covers subdomains, and whether the field carries the preload token. The generated line shows the header name and value that an HTTPS response should reproduce. The point most often missed is that preload is only a declaration of intent. It neither submits the domain nor proves that the live site's HTTPS and redirect behavior qualifies for a browser preload list.
A concrete input and expected output from the current implementation.
Input
max-age = 31536000 seconds; includeSubDomains = enabled; preload = enabled
Expected output
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The numeric value is preserved as seconds, and each enabled option becomes a valueless directive. The duration is exactly 365 days because 365 x 24 x 60 x 60 = 31,536,000.
The value after max-age is a non-negative number of seconds. Enabling includeSubDomains adds a flag directive extending the policy to subdomains, while enabling preload adds the preload token. The builder joins the selected pieces with semicolons under the Strict-Transport-Security field name. Browsers accept this policy only when it arrives over a secure connection.
The preload check evaluates the configured max-age and required directives as a candidate for a browser preload program. It does not turn the header into a preload-list entry. Operational conditions such as valid HTTPS service, redirect behavior, and subdomain coverage belong to the deployed site, so a configuration-level pass is not proof of acceptance.
Not by itself. A browser that has never learned the policy can still send its first request over HTTP, so the origin should redirect HTTP to HTTPS. A preloaded domain is different because the browser already knows its policy. The generated header governs learning and renewal after a secure response; it does not retroactively secure an earlier request.
No. The directive signals an intention to meet preload requirements, but inclusion requires separate submission and verification, followed by incorporation into browser preload data. The builder can assess the selected header values. Generating the field alone neither submits the domain nor establishes that browsers currently recognize it as preloaded.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.