HTTP caching · RFC 9111
Cache-Control header analyzer
Will a response be cached, by the browser and by a CDN, and for how long? Paste the headers and find out.
Open the full analyzer ↗How it reads your headers
Storability: no-store blocks all caching; private limits storage to the
browser; Vary: * blocks shared caches.
Freshness: shared = s-maxage → max-age → Expires−Date; browser =
max-age → Expires−Date.
Revalidation: no-cache checks the server every time; must-revalidate
forbids serving stale; immutable skips revalidation while fresh.
Validators: an ETag/Last-Modified enables cheap 304s instead of refetching.
Questions
Paste a response's caching headers — Cache-Control, Expires, Date, Age, ETag, Last-Modified, Vary, Pragma — and it tells you, in plain English, whether a browser and a shared (CDN/proxy) cache will store the response, how long it stays fresh, when it revalidates, and any contradictions. It follows the response-side rules of RFC 9111.
They obey different directives. "private" lets only the browser store the response; "s-maxage" sets the freshness for shared caches and overrides "max-age" there; "Vary: *" blocks shared caching entirely. Splitting them shows exactly what your CDN does versus what the visitor's browser does.
Shared caches use s-maxage, else max-age, else Expires minus Date. Browsers use max-age, else Expires minus Date. Expires is only resolved when you paste both the Expires and Date headers, since freshness is measured from the response Date. With none of these, caches fall back to heuristics.
No. All parsing and analysis run entirely in your browser. Nothing you paste leaves the page — there is no backend and no logging.
Run "curl -I https://example.com/asset", or open your browser DevTools → Network → click the request → Response Headers, and copy the lines. Paste them as-is; non-caching headers are ignored.