Skip to content
TabBench

HTTP Header Analyzer

Paste request or response headers from curl, DevTools or logs. Each header is explained, security and caching problems are flagged, and cookies and CORS are checked.

Runs in your browser. Nothing you add is uploaded.

What the HTTP Header Analyzer does

HTTP headers carry the instructions that decide how a page is cached, secured and shared across sites, yet they are hard to read in a wall of text. Paste the headers from curl, your browser's Network tab or a server log, and this viewer explains each one, groups the problems it finds, and shows how long a response can be cached. It is a quick way to check a site's security headers, debug a caching problem or understand why a cross-origin request is blocked, without sending your headers to anyone.

How to check HTTP headers

  1. Get the headers: run curl -I https://example.com in a terminal, or open your browser's developer tools, choose the Network tab, select a request and copy its headers.
  2. Paste them into the box. A status line (HTTP/2 200) or a request line (GET /path HTTP/1.1) is optional.
  3. Read the summary: the number of headers, problems and, for responses, how many of the six key security headers are set.
  4. Open the findings to see each problem with an explanation, then select a header in the list for its meaning and a breakdown of its value.
  5. Fix the issues on your server with the HTTP Header Generator, then paste the new headers to confirm.

The HTTP Header Analyzer runs entirely in your browser — nothing you enter is uploaded, stored, or logged.

When to use it

Checking a site's security headers

After a deploy, confirm that HSTS, Content-Security-Policy, X-Content-Type-Options and framing protection are really being sent, and that values such as unsafe-inline or a short HSTS lifetime have not crept in.

Debugging caching

If a CDN keeps serving an old file or never caches a new one, the Cache-Control, Vary and ETag headers usually explain why. The viewer translates them into what a browser and a CDN will actually do.

Understanding a CORS error

Paste the response headers of the failing request and the viewer shows whether Access-Control-Allow-Origin is present, whether it conflicts with credentials and whether Vary: Origin is missing.

Good to know

  • curl -sIL https://example.com shows the headers of every hop in a redirect chain; paste the whole output and switch between responses.
  • Header names are case-insensitive. HTTP/2 requires lower case, which is why Chrome shows them that way.
  • Set-Cookie can appear several times in one response. Each cookie is checked on its own.
  • Remove Authorization and Cookie values before pasting into a bug report or screenshot.
  • A missing header is not always a problem: Strict-Transport-Security only matters on HTTPS.

Frequently asked questions

Can this tool fetch the headers of a website for me?

No. A web page cannot read another site's response headers because of browser security rules. Run curl -I https://example.com or open your browser's Network tab, copy the headers and paste them here.

Are the headers I paste sent anywhere?

No. They are parsed in your browser and never stored. Pasted headers are not saved, even locally, because they often contain cookies and tokens.

What does the security checklist mean?

It shows whether six widely recommended response headers are present. A header being present is not proof it is configured well, so the findings below the checklist look at the actual values.

Which security headers matter most?

Strict-Transport-Security to force HTTPS, Content-Security-Policy against cross-site scripting, X-Content-Type-Options: nosniff, a framing policy (frame-ancestors or X-Frame-Options) against clickjacking, a Referrer-Policy and a Permissions-Policy. These are the six in the checklist.

Why does the viewer say X-XSS-Protection is obsolete?

The browser XSS filter it controlled has been removed from current browsers, and in some older ones it could create vulnerabilities. The recommended value is 0 or no header at all, with a Content-Security-Policy doing the real work.

What does Vary: Cookie do to caching?

It tells caches to keep a separate copy for every cookie value, so almost every visitor gets a different copy and the hit rate collapses. Avoid it on pages that should be shared.

Related tools