A few notes
on staying fresh.
A cache policy answers more than “how long?” Separate storage, freshness, and validation to understand what a response actually permits.
Getting started
Open your browser’s network inspector, select a response, and find Cache-Control in its response headers. Copy its value into the workbench, enter the current age in seconds, then choose the cache you want to inspect.
- Shared cache: a cache that may serve multiple users, such as an intermediary.
- Browser cache: a private cache associated with one user’s browser.
- Read this policy: shows an estimate from the directives you provide. It does not request the resource.
public, max-age=3600With a current age of 120 seconds, the response has 3,480 seconds — 58 minutes — of freshness left.
Freshness is a countdown.
For an explicit lifetime, the workbench uses:
A response is fresh only while its current age is less than its freshness lifetime. At the lifetime boundary, it is stale. Stale does not necessarily mean unusable: a cache may validate it, or a specific policy may permit limited stale reuse.
The Age header is a useful snapshot, but exact current age also depends on response dates, transit time, and how long the response has resided in a cache. If you copied an older response, account for elapsed time. This tool does not calculate those timings automatically.
The directives, translated.
max-age=N- The response has an explicit freshness lifetime of N seconds.
s-maxage=N- Overrides max-age for a shared cache. For that cache, a stale response must be successfully validated before reuse.
public- Allows shared storage in circumstances where it would otherwise be restricted. It does not set a lifetime by itself.
private- A shared cache must not store an unqualified private response. A private browser cache may still store it.
no-store- The response must not be stored. This is a storage instruction, not a short freshness lifetime.
no-cache- A stored response requires successful validation before reuse. Storage itself is not prohibited.
must-revalidate- Once stale, the response requires successful validation before reuse.
proxy-revalidate- Applies the stale validation requirement to shared caches.
stale-while-revalidate=N- May permit stale reuse for an additional N seconds while validation happens in the background. The workbench does not show this allowance when a stricter validation requirement applies.
Read the policy. Keep the context.
The workbench is a compact explainer, not a complete HTTP cache simulator. It checks the directives above and requires unambiguous, whole-number lifetime values. Unknown extension directives are not evaluated.
A full caching decision can also depend on request method and headers, response status, Authorization, Vary, Expires, validators such as ETag, cache implementation, and local configuration. “Permitted by this policy” does not guarantee that a response will be cached.
Field-qualified private and no-cache require field-level handling; this tool intentionally applies a conservative whole-response interpretation. Without max-age or an applicable s-maxage, it reports an unspecified lifetime rather than guessing. It does not evaluate stale-if-error or immutable behavior.
Small by design. Local by default.
The calculator runs entirely in your browser. Header input is not uploaded, persisted, or included in the page URL. Framecache uses no analytics, third-party scripts, cookies, or external fonts.
Loading these pages still makes ordinary requests to the web host, which may keep standard access logs. Avoid pasting credentials or other sensitive data; this tool only needs cache directives and an age value.
Try a policy