Skip to content

HTTP Header Inspector

Fetches a URL and shows the full response headers, redirect chain, timings and compression used.

One request to a URL, and every response header it comes back with — grouped by what they are for, with Cache-Control broken into its directives and each one explained. It is what a browser sees before it renders anything, which is where cache and compression problems actually live.

☁️ Uses our serverhttpheadersinspectdebug

Our server makes this request for you. Only the URL you typed is sent to it — none of your cookies or login state goes along. The server will only connect to public addresses and refuses private and internal ones.

Up to five redirects are followed, and the headers shown are the last response’s.

How to use it

  1. Give it the URL you actually want

    Up to five redirects are followed and the headers shown are the last response’s. If you care about the redirect itself, the chain is drawn above with the status of each hop.

  2. Read the notes before the tables

    Each note is derived from a specific header — a missing Cache-Control, an Expires that max-age overrides, an HTML response with no charset. They are the findings; the tables are the evidence.

  3. Check the compression line

    The request offers gzip, deflate, br, and zstd; what comes back is what the server chose. A text response with no Content-Encoding is usually 70% larger than it needs to be.

Common questions

Does my login or cookie go with the request?

No. Our server makes the request, so it carries none of your cookies and none of your session. That also means a page behind a login will come back as its sign-in page rather than the version you see.

Can I check something on my own network?

No, and deliberately. The outbound fetch resolves the host first and refuses private, loopback and link-local addresses — including a public name that resolves to one. Without that rule this page would be a way to make our server probe the inside of someone else’s network.

The headers differ from what devtools shows me

Expect that. A CDN varies its answer by geography, by Accept-Encoding, by Vary, and by whether it has a cached copy for that edge. This is one request from one place; your browser is a different one.

Why is Content-Length missing?

Chunked transfer encoding, almost always — the server started sending before it knew the size. It is normal for dynamic pages, and it is why a download from them shows no progress percentage.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.