HTTP Header Analyzer
Explains a block of HTTP headers, checks cookie flags and lists the security headers that are absent.
Loading the tool…
Processing happens locally in your browser.
What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.
How to use this tool
- Paste the header block, from curl -i, from a browser network tab or from a log.
- Leave credential hiding on unless you specifically need to read a token.
- Select Analyse.
- Work through the absent-header rows at the end. They are advice, not failures — this page cannot see how your site is deployed.
What http header analyzer does
Paste the header block from curl -i, from a browser’s network tab, or from a proxy log. Each header is explained in a line, Set-Cookie is checked for the Secure, HttpOnly and SameSite attributes, a wildcard CORS origin is called out, and an HSTS max-age below the usual preload threshold is flagged.
Headers carrying credentials — Authorization, Cookie, API keys — are shown truncated by default, so the result can be screenshotted or pasted into a ticket without leaking the token. That is a display choice, not a security control: nothing here is uploaded in the first place, because the whole analysis runs in your browser.
Frequently asked questions
No. The analysis is JavaScript running in your browser on the text in the box. Nothing is uploaded, which is the reason a header block carrying a live token can be pasted here at all. The truncation of credential values is about what ends up in a screenshot, not about transport.
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy are reported when absent, because those four are the ones whose absence usually matters. They are listed as advice: a page behind a gateway that already sets them, or an API that no browser ever loads, may legitimately not need them.
The three attributes that decide how exposed a session is: Secure, which stops the cookie travelling over plain HTTP; HttpOnly, which keeps it out of reach of JavaScript and therefore of an XSS payload; and SameSite, which is the main defence against cross-site request forgery. Any that are missing are named.
Because it names your server software and version to everyone, and nobody but an attacker looking for a matching exploit has any use for that. Removing it is not a security control on its own, but it costs nothing and takes your stack out of the results of an automated scan.