Browser DevTools -- the Network tab's Headers panel -- shows the raw response
headers for a request you've already made, for free, with nothing to install. It is a fine first
look at what a server actually sent, and for a page you're already inspecting it is often the
fastest option there is. What it does not do is tell you which of those headers, in combination,
form a well-documented misconfiguration: a Vary: * that makes the whole response
uncacheable forever, or a Cache-Control: public alongside a Set-Cookie
header that lets a shared cache leak one visitor's cookie to the next. Reading raw headers in a
panel and knowing what they mean together are two different skills.
This tool sends one request to a URL you name and classifies the response's caching headers into seven named, RFC-backed patterns, stating in plain English why each one matters and which header proves it. It does not replace DevTools -- for a page open in your browser right now, the Network tab is still the quickest way to glance at a response. It automates the reading a person would otherwise have to do by eye, every time, and it runs from a terminal or CI job where clicking through a Network tab isn't practical.
| Question | Where to answer it |
|---|---|
| I have a page open in my browser and want a quick look at its response headers. | DevTools' Network tab -- that quick raw look is exactly its job. |
| I want to know whether a response's caching headers have a named misconfiguration, and why it matters. | This checker -- names the pattern (Vary: *, a public + Set-Cookie leak, and five more) instead of leaving you to notice it in a headers panel. |
| I want this checked automatically on every deploy, with a non-zero exit code on a real problem. | This checker's CLI -- node check.mjs <url> --json exits non-zero on a danger-severity finding. DevTools has no CLI to wire into CI. |
| I'd rather not learn all seven RFC-backed patterns from memory to read a headers panel myself. | This checker -- paste the CLI's JSON into the browser report and get the plain-English findings without already knowing the rules. |
Neither tool replaces the other, and in practice most people use both: DevTools for a fast raw look at one response you're already looking at, this tool for the recurring, automatable question of whether that response's caching headers actually do what they look like they do.
node check.mjs https://example.com --jsonOne request to the URL you name, the same kind your browser already sends. Paste the JSON into the checker for the plain-English report.
Different jobs, and most people who use this tool also still open DevTools. The Network tab's Headers panel shows you the raw response headers for a request you've already made in your browser -- free, already installed, and often the fastest way to check one page you're looking at anyway. It does not tell you what those headers mean together: whether a Vary: * silently makes the whole response uncacheable, or whether a Cache-Control: public alongside a Set-Cookie header is a shared-cache cookie leak waiting to happen. This tool reads the same headers DevTools would show you and names the specific, well-documented pattern -- so you don't have to already know the RFC details to notice the problem.
If you already know every pattern this tool checks -- Vary: *, public plus Set-Cookie, no-store beside a leftover max-age, Expires silently overridden by Cache-Control, a stale Expires, a weak ETag on a range-capable response, a static asset with no caching headers -- DevTools plus your own judgement is enough. This tool exists for the times you don't want to re-derive all seven from memory on every response, or when you want the same checks wired into CI as a non-zero exit code, which DevTools' UI cannot do -- it has no CLI and nothing to script against.
No -- it sees the same response headers DevTools already shows you, and nothing more. The difference is entirely in the reading: this tool applies the seven named checks every time, the same way, whether you remember them or not, and it can run from a terminal or a CI job where opening a browser and clicking through the Network tab isn't practical.
No. The CLI's request goes directly from your machine to the URL you name, exactly like the request your browser already makes. The browser report viewer only parses JSON you paste into it yourself, locally in your browser -- nothing about the target, the headers, or the report is sent anywhere. The only thing stored is an anonymous local count of which features were used, with no target URLs or header values in it.
Chasing a specific symptom instead? Why isn't my CDN caching this? walks the six response-header reasons in the order worth checking them. Prefer a command-line comparison? See this checker vs. curl -I.