Cache-Control Header Builder
Assemble compatible HTTP caching directives and read their combined meaning.
Build an intentional HTTP caching policy
Cache-Control directives answer separate questions: who may store a response, how long it stays fresh, whether stale reuse is allowed, and whether validation is required. This builder composes public or private visibility with max-age, shared-cache s-maxage, immutable, no-cache, no-store, must-revalidate, and stale-while-revalidate while validating non-negative integer durations and incompatible no-store combinations.
The defaults produce a public response fresh for 3600 seconds in browsers and 7200 seconds in shared caches, marked immutable while fresh, required to revalidate when stale, and permitted 60 seconds of stale service during background revalidation. The first output line is the exact header, followed by a plain explanation of the selected reuse behavior.
Freshness, storage, and revalidation are different
No-cache does not mean no storage; it means a stored response must be revalidated before reuse. No-store is the directive that forbids storage, so this builder isolates it from freshness settings rather than creating a contradictory policy. Nothing is fetched or tested because generation is local in your browser. Verify CDN overrides, validator headers, authenticated content, and asset fingerprinting in deployment.
Frequently Asked Questions
What is the difference between no-cache and no-store?
No-cache permits storage but requires validation before reuse. No-store tells caches not to store the response.
What does s-maxage control?
It sets freshness for shared caches such as CDNs and can override max-age there without changing browser freshness.
When is immutable appropriate?
It fits versioned assets whose URL changes whenever content changes, so a fresh cached response need not be revalidated.
Browse the full set of free, private, in-browser tools.