Cache-Control analyzer

Paste response headers or a single Cache-Control value, choose a private or shared cache, then select Analyze. The analysis assumes a GET response with status 200, no Authorization and matching cache keys. It makes no network request and does not inspect or guarantee storage in a browser cache. Request directives and heuristic freshness are outside the model.

Freshness: a response is fresh exactly when its current age is less than its freshness lifetime. A shared cache uses s-maxage before max-age; a private cache ignores s-maxage for lifetime. Otherwise Expires supplies the lifetime relative to Date, or to receipt time if Date is absent. Negative lifetimes become zero. With no explicit lifetime, freshness remains unknown. Storage permission, freshness and reuse are separate results: no-cache may allow storage but requires revalidation before every reuse, while no-store forbids storage and reuse unless must-understand leaves the decision unresolved.

Age: current age = max(0, receipt time − Date, Age + response delay) + time in cache. Without Date, the apparent-age term is zero and a note is shown. Receipt time must be UTC ISO format, for example 2026-09-16T12:00:00Z, optionally with exactly three fractional-second digits. Delay and time in cache allow decimals from 0 to 2147483648 seconds. For receipt at 12:00:00, Date at 11:59:50, Age 5, delay 2 and cache time 3, current age is 13 seconds. With max-age=60 the remaining fresh time is 47 seconds.

Conditional stale use: stale-while-revalidate (SWR) permits stale reuse while asynchronous revalidation is attempted. Its window begins at the freshness lifetime and excludes the end age. stale-if-error (SIE) requires an eligible error, such as a network/DNS failure or HTTP 500, 502, 503 or 504, and includes its stated upper age. Neither extends the freshness lifetime. Active reports only the age condition, not whether revalidation or an eligible error actually occurred. no-cache and must-revalidate prohibit these unvalidated stale exceptions; proxy-revalidate and applicable s-maxage do so for shared caches. Storage restrictions, invalid directives and Vary: * also make the windows unavailable.

Conservative interpretation: private forbids shared storage. Field-qualified private and no-cache are applied to the whole response; field removal is not simulated. Repeated numeric directives and invalid recognized arguments make the analysis stale. must-understand depends on capabilities for the response status code that this tool cannot establish, so storage remains unknown; private still forbids shared storage. Vary: * requires contacting the origin, and other Vary values require matching request headers. Recognized validators do not prove that an origin request will successfully validate a stored response. Unknown extensions and other headers are listed but ignored. Additional immutable behavior is not modeled.

Header and directive names are case-insensitive. Multiple Cache-Control lines are combined; quoted commas and escapes are supported. An optional HTTP status line must specify 200. Date and Expires support IMF-fixdate in GMT, for example Wed, 16 Sep 2026 12:00:00 GMT. Invalid Date or Age and duplicate Date/Age/Expires are rejected. Invalid Expires means zero lifetime if no higher-priority directive applies. HTTP delta-seconds use digits only; values above 2147483648 seconds are saturated to that limit with a note. Limits: 16384 input characters, 128 lines and 128 directives.

Changing inputs clears the result. Clear results keeps the inputs. Within the app, the session and result are retained. A full reload restores the last successfully analyzed compact inputs and waits for Analyze. Header blocks over 1024 characters stay only in the session; a further compact-state size limit may also omit headers on reload.

Sources: RFC 9111: HTTP Caching, especially sections 4.2 and 5.2, and RFC 5861: stale-while-revalidate and stale-if-error.