Skip to content
koducathome

HTTP Header Inspector

Paste raw HTTP request or response headers to get an explanation of each header and a security-header checklist.

How to use this tool

Steps for using the HTTP Header Inspector.

  1. Copy raw headers from browser DevTools (Network tab → a request → Headers → Raw), from curl -i / curl -I, or from a server log, and paste them into the input.
  2. Optionally keep the first line (HTTP/1.1 200 OK or GET /path HTTP/1.1); it is used to detect whether you pasted a request or a response.
  3. Click Inspect headers. Each header is listed with its line number, category and a plain-English explanation; repeated headers such as Set-Cookie are marked.
  4. For responses, read the Security header checklist and the Findings — these are recommendations, not proof of a vulnerability.
  5. Fix any lines reported as malformed, or switch Message type if auto-detection guessed wrong. Copy or download the plain-text report to share it.

Example

Audit a response with risky cookie and CORS settings

Raw response headers
HTTP/2 200
content-type: text/html; charset=utf-8
set-cookie: sid=xyz; Path=/
access-control-allow-origin: *
access-control-allow-credentials: true
server: Apache/2.4.58 (Ubuntu)
Findings (from the report)
(recommendation) Cookie "sid" is missing Secure, HttpOnly, SameSite
(recommendation) Access-Control-Allow-Origin: * combined with Allow-Credentials: true
(recommendation) server discloses a version (Apache/2.4.58 (Ubuntu))

Common use cases

  • Reviewing a site's security headers before a launch or penetration test.
  • Understanding why a response is or is not cached by a browser or CDN.
  • Debugging CORS by checking the exact Access-Control-* headers a server returns.
  • Checking that session cookies carry Secure, HttpOnly and SameSite attributes.
  • Explaining unfamiliar headers in a curl -i output or a bug report to teammates.

How headers are parsed and what the checklist means

An HTTP/1.x message starts with a start line — a status line like HTTP/1.1 200 OK for responses or a request line like GET /path HTTP/1.1 — followed by Name: value header lines and a blank line before the body. The inspector follows RFC 9110/9112: header names must be tokens (letters, digits and a few symbols, no spaces), whitespace between the name and the colon is rejected, and lines that start with a space or tab are treated as obsolete line folding and joined to the previous header. Anything after the first blank line is treated as the body and ignored. HTTP/2 pseudo-headers that DevTools shows, such as :status, are recognised as well.

Header names are case-insensitive, and some headers legitimately appear several times. Set-Cookie is the classic case — each cookie has its own line and they must not be combined — so every occurrence is listed separately and analysed on its own. Around 50 common headers have built-in explanations covering caching (Cache-Control, ETag, Vary), CORS, content negotiation, cookies, authentication and security; custom or vendor headers are shown with "No description available".

The security checklist covers the response headers most hardening guides recommend: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, clickjacking protection via X-Frame-Options or CSP frame-ancestors, Referrer-Policy and Permissions-Policy. Context matters: CSP and framing protections are important for HTML pages but much less relevant for a JSON API, and HSTS is ignored by browsers when delivered over plain HTTP. Values are checked too — for example a short HSTS max-age, 'unsafe-inline' scripts without nonces, or the obsolete ALLOW-FROM are marked for review.

Findings point out configurations worth a second look: cookies without Secure, HttpOnly or SameSite; SameSite=None without Secure (which browsers reject); Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true (a combination browsers refuse, so it usually signals a misunderstanding); and Server or X-Powered-By values that reveal version numbers. These are labelled as recommendations because only you know the context — a public, cookie-less API can safely use *, for instance. Everything runs locally in your browser.

Limitations

  • Analyses only the text you paste; it does not fetch URLs. Use the API Tester or curl -I to get headers first.
  • The checklist reflects common recommendations, not a full security assessment. A missing header is not automatically a vulnerability.
  • CSP is checked at a high level (presence, unsafe-inline in scripts, frame-ancestors), not validated directive by directive.
  • Explanations cover about 50 widely used headers; vendor-specific headers are listed without a description.

Frequently asked questions

Where do I get raw headers from?

In Chrome or Firefox DevTools open the Network tab, select a request and toggle Raw in the headers view. From a terminal, curl -I https://example.com prints response headers only and curl -i includes the body.

Does a missing security header mean my site is vulnerable?

Not necessarily. These headers are defence-in-depth. A JSON API that never renders HTML gains little from CSP or X-Frame-Options, while a web app with logins benefits a lot. Treat the checklist as recommendations to evaluate.

Why is `Access-Control-Allow-Origin: *` with credentials flagged?

The CORS specification forbids the wildcard when credentials are allowed, so browsers block such responses. If you need cookies or auth headers cross-origin, return the specific requesting origin from an allowlist and add Vary: Origin.

Are duplicate headers an error?

No. Many headers may repeat; their values are combined with commas. Set-Cookie is special: it must never be combined, which is why each cookie is analysed separately.

Should I still send X-XSS-Protection?

Modern browsers have removed the XSS auditor it controlled. Current guidance (for example from OWASP) is to omit it or send 0, and rely on a Content-Security-Policy instead.