HTTP Headers Checker

Inspect the response headers any URL returns.

This tool sends your query through our server to look up live data. We don't store it, and no files are ever uploaded — though the upstream service answering the lookup sees the query too.

Shows every response header a URL returns — including the security headers a review asks about — with each redirect along the way listed as its own status-badged block rather than folded into the final answer.

How to use it

1Enter the URL and press Enter, or click Check Headers.
2Read the coloured status badge on each block — green 2xx, yellow 3xx, orange 4xx, red 5xx — followed by that hop's headers as a name/value table.
3Use the copy button under the last block to take the final response's headers as name: value lines.

Example

Input: https://example.com
Output: One block badged 200 listing example.com's response headers as rows — content-type, server, last-modified, cache and CDN headers among them

Header names appear lower-cased because that is how the fetch implementation normalises them, so Content-Type reads as content-type. A URL that redirects produces one block per hop, each labelled "redirect 1", "redirect 2" and finally "final response", letting you see the location header at every step. The chain stops after five redirects, in which case the last block shown is still a 3xx, and a host that does not answer within eight seconds reports "The request timed out."

What happens to your data

The fetch is made from our host by /api/headers, which is what lets you inspect a site without appearing in its logs yourself. It is a GET rather than a HEAD, but res.body.cancel() is called the moment the headers have been copied, so the page's content is never downloaded, parsed or held. Every hop is re-checked against private and loopback address ranges before it is followed, so a redirect into an internal network is refused mid-chain. The chain is assembled in memory and returned; the route writes none of it down.

Last updated August 2026

A change goes live, the page still comes back stale, and someone asks whether the cache-control header you set is actually being sent. Or a security review lands with a list of headers the site is meant to return and no obvious way to see which of them are there. The question underneath both is what this URL really answers with, rather than what the config file says it should.

Decide which URL before you start, because response headers belong to a URL rather than to a site. The apex domain and the www version, http and https, the home page and a deep article, an image and the HTML that references it — each can return a different set. A file served straight from object storage carries none of the headers your application adds, which is how a site with a careful content security policy ends up with assets that have no policy at all.

The second thing to settle is that this is the anonymous, logged-out view, taken from a server rather than from your machine. Nothing here carries your cookies or your session, so a URL behind a login answers the way it answers a stranger, and any header that varies by account is not the one you will see.

The mistake worth avoiding is reading one block and calling a header missing. A URL that redirects produces a response at every step, and headers land on different ones — strict-transport-security belongs on the https response, and a policy set on the final page says nothing about the hop that sent you there. Read the chain rather than the end of it.

How it works

Toolvore makes the request from a server rather than from your browser, with automatic redirect following switched off, so every hop is captured as it arrives instead of being collapsed into the final answer. Each response's header list is copied into a name and value table and the body is cancelled the moment that copy is done, so none of the page itself is downloaded. A location value is resolved against the URL that produced it, so relative redirects are followed correctly, and each new host is checked again before the next request goes out — a redirect pointing into a private or loopback address is refused part-way along the chain. Enter a bare domain and https is assumed. The weak points are worth knowing: headers are gathered as one value per name, so a response sending the same header twice, several set-cookie lines being the usual case, cannot show them as separate rows. Nothing about the connection is reported either — no protocol version, no TLS or certificate detail, no timing — and no request headers, because the request was not yours. The whole chain shares a single eight-second budget rather than one per hop.

Common use cases

Confirming a cache-control change actually reached production
Checking which security headers a site returns before an audit
Tracing an http to www to final page redirect chain
Working out which CDN or origin is answering for a domain
Checking that a file is served with the content-type you expect
Seeing where a shortened link ends up without opening it
Comparing a staging URL's headers against the live one

Frequently asked questions

What is the difference between request headers and response headers?＋

Every exchange has two sets. Request headers are what the client sends: the URL it wants, its user agent, accept and accept-language, any cookies it holds. Response headers are what the server sends back alongside the status line: content-type, cache-control, set-cookie and whatever security policies the site applies. They travel in opposite directions and are set by different people — you control your request headers, the site controls its response headers. A checker like this one can only show the second set, because the request was made on your behalf with a fixed set of fields. To see your own request headers, open the network panel in your browser's developer tools and click the request.

Which security headers should a website be sending?＋

The commonly asked-for set is short. strict-transport-security tells browsers to use https for this host in future, closing the gap on a first plaintext request. content-security-policy limits where scripts, styles and frames may come from, and is the one that takes real work to get right. x-content-type-options set to nosniff stops a browser second-guessing the declared content type. referrer-policy controls how much of the current URL leaks to the next site. frame-ancestors inside the policy, or the older x-frame-options, decides who may embed your pages. permissions-policy switches off browser features the site does not use. Their absence from a response is what a review usually flags.

Why does one URL go through several redirects?＋

Chains build up over years, one rule at a time: http to https, apex to www, an old path to a new one, a trailing slash added. Each is a separate response costing a round trip before anything renders, so two or three hops is ordinary and more is usually redundancy nobody has revisited. Check the codes as well as the count. A 301 or 308 is permanent and gets cached hard by browsers, which makes a wrong one painful to undo, while 302 and 307 are temporary. The 307 and 308 pair also preserve the original method and body, which the older two are not required to do.

Why are the headers different from what my browser's developer tools show?＋

Several ordinary reasons. Your browser sends cookies, a session, an accept-language and a familiar user agent; a server-side check sends none of those, and any response that varies on them will differ. You are also reaching a different CDN edge from a different location, so cache status, geo routing and region-specific headers can all change, and a cached hit often carries different headers from a miss. Some sites treat an unrecognised user agent as a bot and answer with a challenge or a trimmed response. Your browser also shows you the response it settled on after following redirects, which hides what the hops in between returned.

Does the site know I checked it, and where does my URL go?＋

The request is made from this site's server with the user agent toolbox-headers-checker/1.0, so the visit is logged against that server rather than against your address — and the target sees an unfamiliar client, which some sites treat differently. Your URL itself does travel: it is passed to this site's own endpoint as a query parameter so the fetch can be made. Treat a URL carrying a token, a signed expiry or a session id in its query string the way you would treat the credential itself, and check a plain equivalent instead. The response body is cancelled unread, and only the header chain is returned.

Why is my cache-control header not doing what I expect?＋

Usually because more than one cache is involved and they are reading different instructions. max-age applies to every cache including the browser's, s-maxage applies only to shared caches and overrides it there, and many CDNs honour a header of their own ahead of both. no-cache does not mean do not store — it means revalidate before reuse — while no-store is the one that keeps nothing. Then vary decides what counts as the same response, and a vary on user-agent fragments a cache into near-uselessness. An edge already holding an old copy keeps serving it under the old rules until it expires or you purge it.

Why does the content-type header matter so much?＋

It tells the browser what it has been given, and getting it wrong produces the strangest bugs: a stylesheet ignored, JSON rendered as text, markup shown as source. For anything textual the charset parameter matters as much as the type — text/html with no charset leaves the browser guessing, and a wrong guess is how accented characters turn into rubbish. Browsers historically sniffed the bytes and overrode the declared type, which was a security problem as much as a correctness one, and nosniff is what turns that off. content-disposition is the related header deciding whether a file opens in the tab or downloads, and with what filename.

Can I check headers on a page that needs a login, or send my own headers?＋

Not from here. The request goes out anonymous, as a GET, with no cookies, no authorization header and nothing you can add, so a protected URL returns whatever a signed-out visitor gets, usually a redirect to a login page. That covers most audits, since the headers people check are set on public responses. When you need an authenticated view, or a method other than GET, curl is the tool: curl -I sends a HEAD request, curl -sD - -o /dev/null shows response headers from a normal GET, and -H adds your own. The browser network panel works too, using the session you already have.