Security Headers Checker

The Security Headers Checker is a free online tool that paste http response headers to analyze security config with grading, csp/hsts/cookie checks, and cross-origin policy analysis.. It runs entirely in your browser with no installation or sign-up needed.

CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, X-XSS-Protection, Cache-Control, and Set-Cookie security flags.

Each header is weighted by severity. Proper config earns full weight, misconfigured earns partial, missing earns zero. Total maps to A+ through F.

Yes. All analysis runs in your browser. No data sent to any server.

Yes, the Security Headers Checker is 100% free with no registration, no hidden fees, and no usage limits. All processing happens locally in your browser, ensuring complete privacy.

Yes, the Security Headers Checker is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Security Headers Checker in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The Security Headers Checker works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

There are two quick ways. From the command line, run curl -I https://example.com and copy the response, which prints each header on its own line. From the browser, open DevTools, switch to the Network tab, reload the page, click the top document request, and copy the Response Headers section. Either way, paste the lines into the box in Key: Value format, one header per line. The leading status line such as HTTP/2 200 OK is fine to include and is skipped automatically. Because the curl and DevTools methods request the page as a real client, they capture the exact headers a browser receives, including Set-Cookie and cache directives. If you just want to see how grading works, load the built-in Secure or Weak example instead and inspect the per-header breakdown.

A strong HSTS header tells browsers to only ever connect over HTTPS for a long time and to cover every subdomain. The checker looks for three things: a max-age of at least 31536000 seconds (one year), the includeSubDomains directive so subdomains inherit the same HTTPS-only rule, and the preload flag. A short max-age, like a few days, leaves a long window where a downgrade or man-in-the-middle attack can strip HTTPS, so the tool flags anything under a year and shows the value in days. The preload flag matters because it makes your domain eligible for the browser HSTS preload lists shipped in Chrome, Firefox, and Safari, which enforce HTTPS even on a user's very first visit. Paste your headers to see exactly which of these three pieces your HSTS is missing.

Both defend against clickjacking by controlling whether your page can be embedded in an iframe, but frame-ancestors is the modern replacement. X-Frame-Options is older and only supports DENY and SAMEORIGIN reliably; its ALLOW-FROM value is deprecated and ignored by Chrome, Firefox, and Safari, so the checker marks ALLOW-FROM as misconfigured. The Content-Security-Policy frame-ancestors directive does the same job but is more flexible: it accepts a list of allowed origins and is honored consistently across current browsers. Best practice is to ship frame-ancestors 'none' or a specific allow-list in your CSP, and keep X-Frame-Options: SAMEORIGIN only as a fallback for very old browsers. The tool checks for a missing frame-ancestors directive in your CSP and flags it separately. Paste your headers to confirm your clickjacking protection covers both layers correctly.

It looks backwards, but 0 is the correct modern value. X-XSS-Protection enabled a legacy XSS auditor that older browsers built in, but that auditor had known bypasses and, worse, could itself be abused to selectively disable parts of a page or leak whether certain content was present. Modern browsers have removed it entirely, so a value like 1; mode=block does nothing useful and can give a false sense of safety. Explicitly sending X-XSS-Protection: 0 turns off any residual legacy behavior in browsers that still recognize the header. The real defense against cross-site scripting today is a strict Content-Security-Policy that blocks inline and untrusted scripts, which is why the tool weights CSP heavily and treats this header as deprecated. Paste your headers to see whether your CSP is doing the heavy lifting instead.

The checker inspects every Set-Cookie header for three flags: Secure, HttpOnly, and SameSite. Secure ensures the cookie is only sent over HTTPS, so it cannot be intercepted on an unencrypted connection. HttpOnly hides the cookie from JavaScript, which stops an XSS payload from stealing a session token through document.cookie. SameSite controls whether the cookie is sent on cross-site requests; Strict or Lax helps block cross-site request forgery, while None requires Secure to be present. Session and authentication cookies should carry all three, and the tool flags any cookie missing them so you know which ones leave a user exposed. Because everything is parsed in your browser, you can safely paste authenticated responses that contain real Set-Cookie values. Paste your headers to get a per-cookie list of which flags are set and which are absent.