Cache-Control Analyzer & Builder
Explain Cache-Control headers for browsers and CDNs, then build one from TTLs
Input
Paste a Cache-Control value or full response headers.
Results
Directives
Related Tools
What it does
Cache-Control Analyzer & Builder explains how browsers and shared caches such as CDNs treat a response. Paste a Cache-Control value or the full response headers to see the freshness lifetime for each kind of cache, the current age, when revalidation happens, who may store the response, and a list of findings with recommendations. Build mode turns TTLs and options into a header and analyzes the result the same way.
How freshness is calculated
Following RFC 9111, shared caches use s-maxage, then max-age, then Expires minus Date. Browsers use max-age, then Expires minus Date. Without any of these, caches may estimate a heuristic lifetime from Last-Modified; the tool reports that instead of guessing a number. The current age comes from the Age header, and optionally from the time elapsed since the Date header.
Common misunderstandings
no-cache does not mean do not store: it means store, but revalidate before every reuse. Only no-store prevents storage. private keeps a response out of shared caches but not out of the browser cache. s-maxage overrides max-age only in shared caches. must-revalidate forbids serving a stale response, which also disables stale-while-revalidate and stale-if-error in most caches.
Parsing rules
Directive names are case-insensitive and separated by commas; quoted values such as private="Set-Cookie" may contain commas. Duplicate directives are flagged and the first occurrence is used. Invalid numbers such as max-age=abc are errors and make the response stale. Unknown extensions are listed as info, and likely typos such as maxage get a suggestion.
Privacy
Parsing and analysis run in your browser. Pasted headers are not saved or sent anywhere; only the selected mode and the Date option are remembered on this device. Cookie values in pasted headers are never displayed in the results.
