Reading a response’s headers cross-origin is deliberately restricted by the browser’s Same-Origin Policy and CORS: JavaScript on our page can only see a handful of “safelisted” response headers from a different origin, and essentially none of the security headers you care about. Many tools work around this with a server-side proxy that fetches the URL for you — but that means sending your URL (and your site’s configuration) to their server. We deliberately don’t do that, which is what keeps everything private and lets you check staging or internal sites. So the reliable path is to get the headers yourself: run curl -I https://your-site.com (or curl -sD - -o /dev/null https://your-site.com) in a terminal, or open DevTools → Network, reload, click the top document request and copy the Response Headers — then paste them in. The optional “try to fetch” box only demonstrates the CORS limit.

The 0–100 security score is a weighted roll-up of the key security headers. The biggest weights go to Strict-Transport-Security (HSTS) and Content-Security-Policy, then X-Frame-Options (or CSP frame-ancestors) and X-Content-Type-Options: nosniff, then Referrer-Policy, Permissions-Policy and the Cross-Origin-Opener / Resource-Policy headers. Each contributes proportionally to how strong its value is — for example HSTS scores higher with a one-year+ max-age plus includeSubDomains, and CSP scores lower if it relies on unsafe-inline / unsafe-eval. Small penalties are subtracted for advertising the deprecated X-XSS-Protection or leaking your stack via Server (with a version) and X-Powered-By, which OWASP recommends removing. The result maps to an A–F grade with a plain-language verdict. It reflects header hygiene against best practice, not a guarantee — it’s guidance, not a penetration test.

The report has four groups. Security is the OWASP set. SEO covers the headers a crawler reads: it flags a header-level X-Robots-Tag noindex or nofollow PROMINENTLY (a header noindex overrides any index meta tag and removes the URL from search), and checks the Link rel=canonical (the way to canonicalize non-HTML files like PDFs), Content-Type with a declared charset, Content-Language and Vary. Caching / performance covers Cache-Control (long-cache fingerprinted assets, revalidate HTML), the ETag / Last-Modified validators that enable cheap 304 revalidation, and Content-Encoding (gzip / brotli / zstd compression). A fourth Server group surfaces fingerprinting headers to minimize (Server, X-Powered-By) and any redirect Location. Each header has its own card with the value found and a concrete fix.

The HTTP Header Checker is 100% client-side. The headers you paste are parsed and checked locally in your browser; nothing is fetched, uploaded, logged or stored on a server, and no site is ever contacted (there is deliberately no server proxy). Unlike online header scanners that fetch your URL server-side — exposing which URL you’re testing and its configuration — this is safe for staging, internal or pre-launch sites whose headers you don’t want to send to a third party. It works offline once cached as a PWA, and closing the tab discards everything you entered. It is honest about scope: it only sees the headers you paste (not your TLS config, cookie flags or runtime behaviour), so treat it as best-practice guidance and confirm with your server config plus a dedicated scanner like securityheaders.com or Mozilla Observatory.