Cache-Control Guru
Generate and understand HTTP caching headers easily
Common Patterns:
Configure options or enter a Cache-Control header above to see an explanation.
Configure Options
1. Cache Type
Determines which caches can store the response.
Response can be stored by any cache, including browsers and CDNs. Use for content that can be shared among users, such as static images or CSS files.
Response is intended for a single user and must not be stored by shared caches like CDNs. Use for personalized content, like user-specific pages.
Response must not be stored in any cache. Used for sensitive data that should never be cached. Overrides all other directives.
2. Freshness Duration
Controls how long the response can be used before it becomes stale and potentially needs revalidation.
Prevents unnecessary revalidation specifically during page reload/refresh. While browsers normally use cached responses during navigation, they typically revalidate all resources when a user explicitly refreshes the page. This directive tells browsers "don't revalidate even on refresh."
3. Cache Behavior for Fresh Responses
Controls whether fresh responses (within their freshness lifetime) can be used without checking with the server first.
How should caches handle responses that are still fresh?
This is the default browser behavior for normal navigation. Browsers use cached responses within their freshness period without checking with the server.
Caches can serve the response directly without contacting the origin server as long as it's within the max-age timeframe.
Note: During page refresh/reload, browsers typically still check with the server even for fresh responses. To prevent this, use the 'immutable' directive in the Freshness Duration section.
Requires checking with the server before using any cached response. Note: This does NOT mean "don't cache" - the browser will still store the response, but must validate it before use. For content that should never be stored, use "no-store" instead.
4. Cache Behavior for Stale Responses
Controls how caches handle responses after they've become stale (exceeded their freshness lifetime).
Once a response becomes stale, the cache MUST verify it with the origin server before reuse. Prevents caches from using stale responses when disconnected from the origin.
Ensures that stale responses are not used without checking with the server, improving accuracy.
Similar to must-revalidate but only applies to shared caches like CDNs. Allows browser caches to serve stale content offline while requiring CDNs to revalidate.
Allows private caches to serve stale responses while requiring shared caches to revalidate.
Advanced Staleness Options
5. Other Directives
Additional controls that can be applied to all responses regardless of cache status.
Prevents caches from modifying the response content (like image compression). Ensures content integrity by preventing proxies from altering your content in any way.
Use Case: Add this when proxies should not compress your images, transform your JSON formats, or alter your content in any way that would change the bytes received by the client.
Directive Interactions
• no-store overrides all other directives; no caching occurs
• no-cache requires revalidation even for fresh responses, but still allows storing the response
• s-maxage only applies to shared caches (relevant only for Public cache type)
• immutable prevents revalidation on page refresh (HTTP/2+ support varies)
• must-revalidate requires revalidation when stale
• max-age=0 is different from no-cache: max-age=0 makes content immediately stale but doesn't prevent caching
• stale-while-revalidate and stale-if-error provide grace periods for using stale content