Processed locally in your browser — nothing you enter here is uploaded.

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.

Share this utility

Send the tool, not any text or files you entered. Input is never added to the share URL.

Continue the workflow

Website Security Headers Toolkit

Step 4 of 5. Keep the context and finish the related checks.

View full workflow

Where this comes from

Sources and standards

Links last checked August 13, 2026.