Cache-Control Header Generator and Parser

Compose an HTTP caching policy from clear options, parse an existing header, and catch contradictory directives before deployment.

  • Shared caches such as CDNs may store the response.
  • Browser freshness lifetime: 365 days.
  • Fresh responses are declared immutable and should not be revalidated.

What does Cache-Control do?

The HTTP Cache-Control response header tells browsers and shared caches how a response may be stored and reused. A correct policy can reduce latency and origin traffic. A wrong policy can expose private data, serve outdated content, or force unnecessary downloads.

This builder produces a header plus configuration snippets for common deployment environments. The parser accepts a header with or without the Cache-Control: prefix and explains the recognized directives.

Common Cache-Control examples

Fingerprinted static assets

Cache-Control: public, max-age=31536000, immutable

Use a long lifetime only when the asset URL changes whenever its content changes, such as a JavaScript bundle containing a content hash.

HTML that must be revalidated

Cache-Control: no-cache

Despite its name, no-cache allows storage but requires revalidation before the stored response is reused. Use no-store when a response must not be stored at all.

CDN caching with background refresh

Cache-Control: public, max-age=300, s-maxage=300, stale-while-revalidate=86400

This keeps the response fresh for five minutes and allows a shared cache to serve stale content while refreshing it in the background for up to one day.

Important directives

  • public permits shared caches to store a response when other rules allow it.
  • private limits storage to private caches such as a user's browser.
  • max-age sets freshness lifetime in seconds.
  • s-maxage overrides freshness lifetime for shared caches.
  • no-cache requires revalidation before reuse.
  • no-store prohibits storage.
  • immutable tells clients that a fresh response will not change.
  • must-revalidate requires validation after a response becomes stale.

Test the real response

Generating a header does not prove that an application or CDN is sending it. After deployment, inspect the actual response in browser developer tools or with a command such as curl -I. Check redirects and error responses separately because they may follow different rules.

Never apply a public caching preset to personalized pages, authentication responses, checkout data, or other user-specific content without a complete cache-security review.

Standards and related tools

Modern HTTP caching behavior is defined by RFC 9111. Use the Hash Generator for content digests or the SRI Hash Generator when a browser must verify an external script or stylesheet.