HTTP Headers Parser & Security Auditor
Paste raw HTTP response headers to parse them into a table and audit for missing security headers like CSP, HSTS, and X-Frame-Options.
Parsed headers
| Name | Value |
|---|---|
| Content-Type | text/html; charset=UTF-8 |
| Content-Security-Policy | default-src 'self' |
| Strict-Transport-Security | max-age=63072000; includeSubDomains |
| X-Content-Type-Options | nosniff |
| Referrer-Policy | strict-origin-when-cross-origin |
| Set-Cookie | session=abc123; Secure; HttpOnly; SameSite=Lax |
Security header audit
4 of 8 recommended security headers present.-
PresentContent-Security-Policy
Restricts which sources scripts, styles, and other resources may load from — the primary defense against XSS and data-injection attacks.
default-src 'self' -
PresentStrict-Transport-Security
Tells browsers to only ever connect over HTTPS for this domain, preventing protocol-downgrade and cookie-hijacking attacks on future visits.
max-age=63072000; includeSubDomains -
MissingX-Frame-Options
Controls whether the page can be embedded in an <iframe> on another site — the classic defense against clickjacking.
-
PresentX-Content-Type-Options
Set to "nosniff", stops the browser from guessing (MIME-sniffing) a different content type than the server declared, closing a class of content-type confusion attacks.
nosniff -
PresentReferrer-Policy
Controls how much of the current page's URL is sent as the Referer header when a user follows a link elsewhere, limiting accidental information leakage.
strict-origin-when-cross-origin -
MissingPermissions-Policy
Explicitly enables or disables browser features (camera, geolocation, microphone, etc.) for the page and any embedded frames.
-
MissingCross-Origin-Opener-Policy
Isolates the page's browsing context from cross-origin windows it opens, mitigating a class of side-channel (Spectre-style) attacks.
-
MissingCross-Origin-Resource-Policy
Controls whether other origins may load this resource, reducing exposure to speculative side-channel attacks.
About this tool
How to use it
- Copy raw response headers from `curl -I <url>`, browser devtools' Network tab (right-click a request → Copy → Copy Response Headers), or any other source, and paste them in — one "Name: value" pair per line.
- A leading request or status line (like "HTTP/1.1 200 OK") is fine and automatically skipped.
- Click Parse Headers, or just keep typing — the table and audit both update live.
- Check the security audit panel below the table for which of 8 common security headers are present or missing, and what each one actually does.
Why it matters
Security headers are one of the highest-value, lowest-effort defenses a server can add — a single missing Content-Security-Policy or X-Frame-Options header can leave a site open to attacks that a one-line server config change would have closed. Reading through raw header dumps by eye is error-prone; a checklist makes the gaps obvious.
When to use it
Auditing your own site's response headers before or after a security review. Comparing what headers a server actually sends against what its config claims to set (a surprisingly common mismatch, especially behind a CDN or reverse proxy that can silently strip or override headers). Understanding what an unfamiliar header your team already uses actually does.
Good to know
The 8 headers checked (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy) are the commonly-recommended set from the OWASP Secure Headers Project and MDN's web security documentation — this only checks for their presence and shows their value, it does not validate that a present header's value is actually configured correctly (a Content-Security-Policy of "default-src *" technically satisfies the presence check while providing little real protection). A header being 'present' here means it appeared in what you pasted; always confirm against the live response, since proxies and CDNs can add, strip, or rewrite headers between your server and the browser.
Common questions
Where do I get raw response headers to paste in?
Run `curl -I https://example.com` in a terminal, or in most browsers' devtools: open the Network tab, reload the page, click the request, and look for a "Copy Response Headers" option (usually in a right-click context menu on the request).
A header is marked 'Present' but my site still isn't secure — why?
This tool only checks whether a header exists, not whether its value is actually a strong configuration. A Content-Security-Policy of `default-src *` is technically present but provides almost no protection — always review the actual value, not just the checkmark.
Why is a header I know my server sends showing as missing?
Most commonly because it was stripped or not paste — double-check you copied the response headers (not request headers), and that no CDN, load balancer, or reverse proxy in front of your server is removing it before it reaches the browser.
Is my header data sent anywhere?
No. Parsing and the security audit both run in plain JavaScript in your browser tab — nothing you paste is uploaded, logged, or stored.
Why isn't X-XSS-Protection in the audit list?
X-XSS-Protection is deprecated — modern browsers have removed support for it in favor of Content-Security-Policy, so recommending it would be outdated advice. This tool only checks headers that current browser security guidance still recommends.