HTTP caching policy
Cache-Control Header Parser & Builder
Separate directives safely, validate delta-seconds, expose contradictory policies, normalize an existing field value, or assemble a response policy without memorizing syntax.
Input is processed locally in this browser
Cache-Control parser workspace
Normalized field value
public, max-age=300, s-maxage=3600, stale-while-revalidate=60public
Boolean directive
max-age
300
s-maxage
3600
stale-while-revalidate
60
Make cache intent explicit before deployment
Cache-Control carries request or response directives that control storage, freshness, validation, and reuse. A syntactically valid field can still express a confused policy: public, private conflicts, while no-store, max-age=3600 gives a freshness lifetime to a response that compliant caches should not store.
How to use the Cache-Control parser
- Paste a Cache-Control field value in Parse mode and inspect each normalized directive.
- Correct malformed delta-seconds, duplicates, or contradictory visibility and storage controls.
- Switch to Build mode to choose response directives and explicit freshness windows.
- Deploy the copied value, then verify the actual origin and CDN response headers across authenticated and anonymous requests.
| Directive | Operational meaning | Common mistake |
|---|---|---|
| no-cache | Store, but validate before reuse. | Describing it as no storage. |
| no-store | Do not store this response. | Combining it with long freshness. |
| s-maxage | Shared-cache freshness override. | Expecting it to control browser cache. |
| immutable | Fresh response will not change. | Applying it to unhashed mutable URLs. |
What the validator can and cannot prove
Directive grammar and core semantics follow RFC 9111 §5.2. The parser keeps extension directives rather than rejecting them, because HTTP caching permits registered or deployment-specific extensions.
A header alone does not prove a response will be cached. Status-code defaults, method, authentication, Set-Cookie, Vary, validators, request directives, framework overrides, and CDN settings still matter. Treat the result as field-level validation, then confirm with a cold request, a warm request, response age, and provider cache diagnostics.
Frequently asked questions
What is the difference between no-cache and no-store?
no-cache allows a cache to store a response but requires successful validation before reuse. no-store tells caches not to store the response. Neither directive is a synonym for immediately expired content.
Does s-maxage override max-age in a browser?
No. s-maxage applies to shared caches such as a CDN and overrides max-age there. A private browser cache still uses max-age or other applicable freshness information.
Can this builder guarantee a CDN caches the response?
No. The complete request, response status, authorization, cookies, Vary fields, surrogate configuration, framework behavior, and CDN rules can all change cacheability. Verify the deployed response and cache-status headers.
Is a pasted cache policy transmitted to Toolk?
No. Parsing, normalization, policy generation, and conflict checks run in the browser. Page analytics do not receive the Cache-Control value entered here.
Related developer tools
Last updated: August 29, 2026
Need a different tool?
Browse all 99 browser-based tools (99 currently marked free), or tell us what useful utility we should build next.