HTTP Header Analyzer

Making sense of response headers

HTTP response headers control caching, content type, cookies, and a whole layer of browser security that is invisible until something goes wrong. An analyzer takes a pasted block of headers, explains what each one does, and flags which security headers are absent, turning a wall of key-value lines into an actionable checklist.

The security headers worth checking

A handful of headers do heavy lifting. Strict-Transport-Security forces HTTPS on future visits. Content-Security-Policy limits where scripts and other resources may load from, the main defense against XSS (build one with the CSP builder). X-Content-Type-Options: nosniff stops the browser from second-guessing content types, and X-Frame-Options or a CSP frame-ancestors directive blocks clickjacking.

Example

HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=63072000
cache-control: public, max-age=3600
x-content-type-options: nosniff
# missing: content-security-policy
# missing: x-frame-options

Here HSTS and nosniff are present, but the absence of a CSP leaves the page more exposed to injected scripts, which an analyzer would highlight.

Reading the subtle ones

Cache-Control interactions trip people up: a no-cache value still stores the response but revalidates it, while no-store forbids storing at all. A Set-Cookie without HttpOnly and Secure flags is a frequent, quietly dangerous finding.

FAQ

Are the X- headers still needed with a CSP? A modern CSP can replace X-Frame-Options via frame-ancestors, but keeping the older header helps for browsers or crawlers that lag.

Why does my HSTS not take effect? HSTS is only honored over HTTPS and after the first successful secure response. Served over plain HTTP, the header is ignored.