Cache-Control Header Explainer
Paste a Cache-Control header and see what each directive means for browsers and CDNs, with warnings for contradictions and presets for common cases.
Free · No sign-up · Your inputs stay in your browser
Input
Explain a Cache-Control header
Output
Fresh for 365 days
| Directive | Meaning |
|---|---|
| public | Any cache may store it, even a response to a request with Authorization. |
| max-age=31536000 | Fresh for this many seconds in any cache, browser included. (365 days) |
| immutable | Will never change while fresh, so the browser skips revalidation on reload. For fingerprinted assets. |
Defined in RFC 9111. With no freshness directive, caches may guess a lifetime from Last-Modified, which is why an HTML page with no header can still be served stale; send no-cache for HTML and a year plus immutable for assets whose file names change with their content.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
no-cache does not mean do not cache
It means store, but revalidate before every use, which with an ETag costs a 304 and no body. no-store is the directive that keeps a response out of every cache, and the right one for pages with personal data. Both are defined in RFC 9111.
Two settings cover most sites
Assets whose file name contains a content hash, as Vite and Next.js produce, never change: public, max-age=31536000, immutable. HTML that names those assets must be checked every time: no-cache. Between the two, s-maxage lets a CDN or Varnish keep a page longer than browsers, and stale-while-revalidate serves the old copy while fetching a new one.