HTTP caching policy
Cache-Control Header Parser and Builder
Parse or build Cache-Control directives and review conflicts. Use the report to inspect a proposed browser or shared-cache policy.
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
Parse or build Cache-Control directives and review conflicts. Use the report to inspect a proposed browser or shared-cache policy. A header alone does not prove that a CDN stores or serves a response. Request directives, authorization, status, Vary, validators, and cache configuration affect behavior. Compare the generated policy with actual response headers and the cache's documented rules.
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 tools
Last updated: September 15, 2026