Client-Side Only — Headers are analyzed entirely in your browser. No data is sent to any server.

HTTP Header Checker

Instant Analysis

Paste any HTTP response headers and get security, CORS, and cache analysis in real-time.

Security Scoring

Get a 0-100 security score based on 9 critical headers with detailed recommendations.

Header Explanations

Click any header to learn what it does, why it matters, and how to configure it.

About the HTTP Header Checker

The HTTP Header Checker (also known as an HTTP header analyzer) is a browser-based tool for checking HTTP response headers — security headers, CORS configuration, and cache directives — without proxying through any third-party server. Paste a raw response (from curl -I, browser DevTools, or any HTTP client), and the checker scores it against the OWASP Secure Headers Project recommendations and the rules in RFC 9110 (HTTP semantics) and RFC 6797 (HSTS). Use it during pre-deploy security reviews, when debugging why a Content Security Policy is blocking a script, or to verify that your CDN is actually emitting the headers you configured at the origin. Everything runs client-side; the response text you paste never leaves your browser tab.

Updated: May 7, 2026

Related Tools

cURL ConverterConvert curl commands to Python, JavaScript, Go, and 18 other languages — useful when scripting header captures.Try it JWT DecoderDecode and inspect JWTs found in Authorization headers without a server round-trip.Try it Hash GeneratorGenerate SHA-256 fingerprints for CSP nonces, Subresource Integrity, and certificate pinning.Try it HTTP Request TesterSend live requests to your endpoints and capture the full response inline.Try it JSON ViewerFormat and explore JSON response bodies once the headers check out.Try it

How to use the analyzer

  • Capture the response headers from your target endpoint. The fastest path is curl -sI https://example.com/ for a HEAD request, or curl -sD - https://example.com/ -o /dev/null when you need the response body discarded but the headers kept. Browser DevTools also work — Network tab, click any request, copy the response headers as text.
  • Paste the raw headers (with or without the HTTP/1.1 200 OK status line) into the input area. The parser handles both folded and unfolded forms and tolerates trailing whitespace.
  • Read the security score (0-100). Each missing or misconfigured header subtracts a documented number of points: HSTS (-20), CSP (-25), X-Frame-Options (-10), X-Content-Type-Options (-10), Referrer-Policy (-5), Permissions-Policy (-5), and the cross-origin isolation triplet COOP / COEP / CORP (-5 each).
  • Inspect the CORS panel for wildcard origins combined with credentials, or for echoed Origin values that bypass the same-origin policy.
  • Inspect the cache panel for Cache-Control TTL, validators (ETag, Last-Modified), and the immutable directive.
  • Click any header row in the table for the per-header explainer with nginx, Express, and Cloudflare configuration snippets.

Common use cases

  • Pre-deploy security audit. Run the analyzer against a staging URL to confirm HSTS, CSP, and frame-protection headers are present before flipping DNS. The score and per-header breakdown make it easy to file actionable tickets ("CSP missing, score 75 → 100").
  • Third-party endpoint scan. When integrating a vendor API or webhook receiver, the analyzer surfaces whether their response sets X-Frame-Options, Content-Security-Policy, or Strict-Transport-Security — a decent proxy for the vendor's overall security posture.
  • CSP debugging. Paste the response from a page that is blocking your inline script or third-party CDN. The analyzer parses each CSP directive (default-src, script-src, style-src, connect-src, img-src, frame-ancestors) and flags the unsafe-inline and unsafe-eval keywords explicitly so you can see exactly what your policy permits.
  • HSTS verification. Confirm that max-age is at least 31536000 (1 year) and that includeSubDomains and preload are set if you intend to submit to the HSTS preload list maintained by Chrome.
  • CDN regression testing. After a CDN config change, paste the new response to verify your edge is still propagating the same security and cache headers as before — a common silent regression when migrating between origin shields or upgrading rule engines.

Privacy and security

The analyzer parses the header text you paste entirely in your browser using the same regex-based parsing rules described in RFC 9110 § 5. Nothing is sent to any server on our side — no proxy, no logging, no analytics on the parsed content. The page never makes an outbound request to your target URL, which means you can safely analyze responses from internal staging hosts, authenticated endpoints (paste curl output that already passed your auth), and pre-production environments without exposing them to third parties.

Tips and pitfalls

  • Do not blindly enable HSTS preload. Once your origin is on the preload list, removal takes weeks to months because the entry is hard-coded into Chromium and Firefox release branches. Confirm every subdomain serves HTTPS first, including legacy mail and admin hosts.
  • CSP with unsafe-inline kills the cross-site-scripting benefit. Per the W3C CSP Level 3 spec, unsafe-inline removes the entire scripting protection that CSP provides; prefer hashes (sha256-...) or nonces over allow-listing inline.
  • X-Frame-Options DENY is overridden by frame-ancestors. The CSP frame-ancestors directive takes precedence in modern browsers (per CSP3 § 6.1), so a CSP allowing self in frame-ancestors will permit framing even if X-Frame-Options DENY is also set.
  • Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true is rejected by every browser per the Fetch standard. The analyzer flags this as a critical CORS misconfiguration.
  • CDNs frequently strip or rewrite headers. Cloudflare, Fastly, and CloudFront each have feature flags or rule engines that can remove security headers added at the origin. Test the public CDN response, not just the origin.
  • Cache-Control: no-store is not the same as no-cache. The MDN HTTP Caching guide is the canonical reference: no-store means do not save anywhere; no-cache means may save but must revalidate before reuse. Mixing them up is one of the most common cache-related security bugs.

Frequently Asked Questions

What is a Content Security Policy and why does it matter?
CSP is a response header that tells the browser which sources of script, style, image, font, frame, and connect endpoints are allowed for the page. A correctly configured CSP shuts down most reflected and stored cross-site-scripting attacks at the browser layer, even if your application has an unpatched XSS bug. The W3C CSP Level 3 specification is the authoritative reference; OWASP's CSP Cheat Sheet is the practical starting point.
Why do I need HSTS if my server already redirects HTTP to HTTPS?
A redirect protects only the second request. The first request — typed URL, link click, or bookmark — still goes out as HTTP and can be intercepted on a hostile network before it ever reaches your redirect. Strict-Transport-Security (RFC 6797) tells the browser to upgrade every subsequent request to HTTPS for the configured max-age window, closing that window on repeat visitors. Add the preload flag and submit to the HSTS preload list to close it for first-time visitors too.
What is the difference between X-Frame-Options and frame-ancestors?
X-Frame-Options is the legacy header (DENY, SAMEORIGIN, ALLOW-FROM) defined in RFC 7034. frame-ancestors is the modern CSP directive that supersedes it. Modern browsers prefer frame-ancestors when both are present, per CSP Level 3 § 6.1. For new deployments use frame-ancestors with an explicit allow-list; keep X-Frame-Options DENY in parallel as a defense-in-depth layer for very old clients.
Does the analyzer check CORS headers?
Yes. It parses Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Expose-Headers. The analyzer flags wildcard-origin-with-credentials (rejected by the Fetch standard), echoed-Origin patterns that effectively defeat same-origin protection, and missing Vary: Origin headers that cause cache-poisoning.
Will my CDN strip the headers I set at the origin?
Sometimes. Cloudflare, Fastly, CloudFront, Akamai, and Bunny each have rule engines or feature toggles that can remove or rewrite response headers. The fastest verification is paste-the-real-public-response into this analyzer rather than trusting the origin alone. Pay particular attention to Cache-Control transformations — some CDNs add public, max-age=N to responses that the origin marked private.
How is this different from securityheaders.com or Mozilla Observatory?
Those services fetch your URL from their own servers and analyze the response there. This tool runs entirely in your browser and analyzes a response you already captured — which means it works on internal staging hosts, authenticated endpoints, and pre-production environments that public scanners cannot reach. The trade-off is that you supply the headers; the analyzer does not fetch them for you.
Can I scan internal IP addresses or hosts behind authentication?
Yes — that is the main reason the tool is paste-driven rather than fetch-driven. Run curl -I against your private host with whatever auth (cookie, bearer token, mTLS) is required, then paste the response headers into the analyzer. The auth credentials you used never need to leave your terminal.
What does the security score actually mean?
The score is a heuristic 0-100 number based on the OWASP Secure Headers Project recommendations. Each missing or misconfigured header costs a documented number of points (CSP -25, HSTS -20, X-Frame-Options -10, etc.). The score is useful for tracking deltas across deploys; it is not a substitute for a full threat model. A score of 100 only means the headers are present and well-formed — your application can still have OWASP Top 10 bugs.
Why does my Cache-Control header look right but pages still go stale at the CDN?
Three common culprits: (a) the CDN ignores your Cache-Control and uses its own internal TTL, configured in the rule engine; (b) you sent Cache-Control: no-cache thinking it meant "do not cache" — it actually means "must revalidate before reuse", so the cache is still in play; (c) you forgot Vary: Cookie or Vary: Accept-Encoding, so the CDN serves the wrong response variant to the wrong client.
Does the analyzer support HTTP/2 and HTTP/3 responses?
Yes. The header semantics are identical across HTTP/1.1, HTTP/2 (RFC 9113), and HTTP/3 (RFC 9114) — only the framing differs. Pseudo-headers like :status are recognized and rendered alongside the regular header set. Paste raw curl --http2 or curl --http3 output and it parses the same way as HTTP/1.1.