Why does the inspector show different headers than my browser DevTools?

Some headers (like Set-Cookie or some CSP variants) are filtered out by the browser before JavaScript can see them. The server-side request sees the raw response, so this view is closer to what curl would show.

What's the difference between GET and HEAD?

HEAD asks for headers only — no body. Use HEAD when you want to check headers on a large file (a video, an installer) without downloading the bytes.

Are 'missing' security headers a problem?

Not necessarily. A static marketing site doesn't need a strict CSP. But a logged-in app missing HSTS, CSP, and X-Frame-Options is leaving easy wins on the table.

Do you follow redirects?

Yes — up to five hops. The chain is shown with status codes for each step.

Developer Tools

HTTP Headers Inspector

See every response header a URL returns, the redirect chain, and which security headers are missing.

Securely processed on our servers

Files are deleted automatically within 1 hour.

About HTTP Headers Inspector

HTTP Headers Inspector sends a real HTTP request to a URL from a server and shows you every header that comes back: cache-control, content-type, set-cookie (sanitized values are still shown), CDN markers, server fingerprints, and the full security header set. Each redirect in the chain is shown with its status code so you can see exactly where a URL ends up. Browsers don't expose response headers to JavaScript across origins, which is why the request happens server-side. The inspector follows up to five redirects and supports both GET and HEAD — pick HEAD if you want to skip the body and just see headers (useful for big files). The security header section calls out which of the standard set you have (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP) and which are missing. Missing ≠ broken — but it's the easiest way to spot a forgotten security policy. Common use cases: debugging why a CDN isn't caching a response (look at cache-control, vary, age); confirming a security header rolled out everywhere; checking what cookies a third-party tag drops; seeing whether a 301 chain is wasting RTTs.

How HTTP Headers Inspector works

Enter a URL and pick GET (full request) or HEAD (headers only).
The server makes a real HTTP request with a normal User-Agent.
Up to five redirects are followed and each hop is recorded.
Response headers are returned verbatim, including duplicates collapsed by the platform.
The known security header set is checked and gaps are surfaced as 'missing'.

When to use HTTP Headers Inspector

Debug missing or wrong cache-control headers on a CDN-fronted asset.
Verify HSTS, CSP, and other security headers shipped after a config change.
Inspect set-cookie attributes (Secure, SameSite, HttpOnly) from a third-party script.
Trace a marketing redirect chain to find where it actually lands.
Identify the server or CDN behind a domain (server, x-served-by, cf-ray, x-vercel-id).
Confirm content-encoding and content-type for a binary asset.

Why choose Utilix HTTP Headers Inspector

Shows the full redirect chain with status codes — most curl one-liners don't.
Calls out missing security headers so gaps don't hide.
HEAD support skips the body for fast checks on large files.
Free, no signup, runs from a server so CORS doesn't block you.