HTTP Headers

Inspect response headers, status, redirect chain and security headers.

Result

No result yet

Enter the inputs above and press Run. Results appear here in a moment.

Monitor this 24/7 — get alerts on the first failure.

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.

What is HTTP Headers?

HTTP headers are the metadata of every web request and response — content type, caching policy, security headers, server identification, cookies, CORS rules. They control browser behaviour, intermediary caching, and a huge portion of web security posture. "Why isn't my CSP working?" is usually answered by reading the actual response headers, not by guessing what the server is configured to send.

This tool sends a real HTTP request to any URL and reports back every response header verbatim, the status code, the final URL after redirects, response timing, and the body's content type and size. Same view your browser's Network tab would give, but shareable, archivable, and runnable from a server's perspective rather than your laptop's.

How it works

Each request is a configurable HTTP transaction:

1Parse and validate URL — Must be http:// or https://. Hostname must not be a private/internal IP (we block lookups to private space to prevent the tool being used as an internal scanner).
2Issue GET or HEAD request — GET fetches the body (size reported, content not displayed for binary types). HEAD requests headers only — faster, and some servers behave differently for HEAD (CDN edge logic, caching layers).
3Optionally follow redirects — 30x responses chain to the next URL. Default: follow up to 10 redirects, report the chain and the final destination. Disable to inspect the redirect response itself (Location header, Set-Cookie on the 30x).
4Capture full header set + timing — Every response header in order, with duplicate handling preserved (some headers like Set-Cookie can appear multiple times). DNS lookup time, TCP connect time, TLS handshake time, time-to-first-byte, total transfer time.

We don't render the page, execute JavaScript, or follow resource requests. This is a pure HTTP-level view — what the server actually returns at the protocol level.

When you'd use it

CDN cache verification

Check Cache-Control, Cache-Status, Age, X-Cache headers to confirm your CDN is caching like you expect. Sub-millisecond Age: 0 means edge missed; Age: 47 means it served a 47-second-old cached response.

Security header audit

Run against your domain, look for Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy. Compare against [securityheaders.com](https://securityheaders.com) grading or your internal hardening checklist.

Redirect chain debugging

User says "the URL keeps redirecting in a loop." Run with follow-redirects on, see the chain. Loop usually shows as the same URL appearing twice — fix at whatever 30x sends to its own predecessor.

Verify deploy of a server config change

Changed Nginx to add a header. Deploy. Run this check — does the new header show up? If yes, deploy is live. If no, config didn't reload or the change is on a different upstream.

Spot leaking implementation details

Look for Server: nginx/1.18.0 (version leak), X-Powered-By: PHP/7.4.3 (stack leak), Via: 1.1 squid (intermediary leak). Production should minimise these — they make reconnaissance easier for attackers and add no operational value.

Reading the result

Status code

200 = OK with body. 204 = OK no body. 301 = permanent redirect. 302 = temporary redirect. 304 = client already has current version. 401 = auth required. 403 = auth provided but insufficient. 404 = path doesn't exist. 500 = server error. 502/503/504 = upstream proxy/origin issues. Treat 5xx as a real problem; treat 4xx as a contract problem (you sent something wrong).

Timing breakdown

DNS lookup = time to resolve hostname. Connect = TCP handshake. TLS handshake = certificate exchange + key agreement. TTFB (time to first byte) = server processing + first byte of response sent. Total = full transfer. High TTFB with low connect = slow server-side processing. High connect with low TTFB = slow network path.

Common security headers

Strict-Transport-Security forces HTTPS on subsequent visits. Content-Security-Policy restricts what scripts can run. X-Frame-Options: DENY prevents clickjacking. Referrer-Policy controls referrer leakage. Missing these isn't a bug, but each one missing is a hardening opportunity.

Caching headers

Cache-Control: max-age=N = cache for N seconds. Cache-Control: no-store = don't cache anywhere. Cache-Control: private = browser can cache, CDN can't. ETag + Last-Modified enable conditional requests (304 Not Modified) to avoid re-transferring unchanged content.

Common pitfalls

Header behaves differently for GET vs HEAD

Some intermediaries (broken CDNs, ancient proxies) serve different responses to HEAD vs GET. If you're debugging caching behavior, use GET — that's what real browsers send for most resources. HEAD is fine for quick header inspection but verify with GET if anything looks odd.

Headers visible in browser DevTools but not here

Browser shows synthesised headers (Sec-Fetch-Mode, etc.) it adds locally, plus headers from preflight/OPTIONS responses, plus headers from the actual response. We only show the actual response headers from the URL you specified. Make sure you're looking at the right request in DevTools, not the OPTIONS preflight.

Different headers from different probers

Geographic CDNs serve different content per region — different cache hit rates, different headers (Cloudflare adds cf-ray with region info). Different Age values across runs are normal. Different Server values usually mean different origin shards.

URL returns a body but Content-Length is missing

Chunked transfer encoding (the response is streamed without a precomputed total length). Common with dynamic content, server-side rendering, large files. Not a bug — just means the server didn't know the final size up front.

Run HTTP Headers on every change, not just once.

Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.

Start free

Frequently asked questions

What's the difference between GET and HEAD?

GET requests the resource and the response body. HEAD requests only the headers — the server processes the request the same way but doesn't send the body. HEAD is useful for checking metadata (file size, last modified, exists?) without transferring content.

Why don't I see headers like User-Agent in the response?

User-Agent is a request header (what we send), not a response header (what the server sends back). The tool shows response headers — what the server returned. Request headers we sent are implicit (HTTP/1.1, GET method, standard Accept: */*, etc.).

How do I know if my Content-Security-Policy is correct?

Read the header value, parse the policy directives, and check whether they match what your app actually loads. CSP violations show in browser console; for a more thorough audit, point a CSP evaluator at the policy string. We surface the raw header value — interpretation is your call.

Why does my redirect chain show different cookies set at each step?

Each 30x response can include Set-Cookie headers — usually for tracking the redirect flow. With follow-redirects on, all those cookies are included in subsequent requests in the chain. If you only want to see what cookies are set at a specific step, disable follow-redirects.

What does "301 vs 302" actually mean in practice?

301 = permanent redirect. Browsers and search engines cache it indefinitely and may not check the original URL again. 302 = temporary, always re-checks. SEO consequences differ: 301 transfers ranking signals, 302 doesn't. Use 301 only when the move is permanent.

Can I send a custom request body or headers?

Not in this tool — it's a passive checker, send-no-body GET/HEAD only. For arbitrary HTTP testing (custom methods, bodies, request headers), you want curl, httpie, or Postman. We're optimised for the "what does the server send back" use case.

What's the difference between Strict-Transport-Security and HSTS?

Same thing. Strict-Transport-Security is the formal header name; HSTS is the policy it enables (HTTP Strict Transport Security). Setting Strict-Transport-Security: max-age=N tells browsers to refuse plain HTTP to this host for N seconds.

Why is my Server header showing a version I don't recognise?

Could be: (1) a CDN/proxy in front of your origin (Cloudflare sends Server: cloudflare, your origin's Server is hidden behind it), (2) a load balancer rewriting headers, (3) an old container image you forgot is still running. Run a check directly against your origin IP to bypass intermediaries and see what your server actually says.