b2KIT

Cache-Control Header Generator

Build Cache-Control HTTP headers with max-age, s-maxage, no-cache, no-store, and immutable directives.

Tested tool guide Tested browser tools Checked August 15, 2026

What Cache-Control Header Generator does, with a checked example

This tool assembles a Cache-Control header value from separate controls: a max-age field for browser and shared-cache freshness in seconds, an s-maxage field aimed specifically at CDNs and reverse proxies, and toggles for no-cache, no-store, public, private, and immutable. Selected directives are joined into one comma-separated value in a consistent, readable order; Cache-Control directives are parsed as an unordered list, so caches interpret the header the same way regardless of the order they appear in. The detail people get wrong most often: no-cache does not block caching. It lets a cache store the response but forces revalidation before every reuse, while no-store is the only directive that actually prevents storage.

Worked example

A concrete input and expected output from the current implementation.

Input

max-age=86400, public checked, immutable checked

Expected output

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

max-age=86400 lets any cache reuse the response for 24 hours, public additionally makes the response shareable even on a request that carried an Authorization header (without public, such a response generally can't be stored by shared caches, even with max-age present), and immutable tells supporting browsers to skip revalidation on an ordinary reload while the cached response is still fresh.

How the result is produced

1

Directive assembly order

Each active field or checkbox contributes one directive to the header string in a fixed presentation order: visibility directives (public/private) first, then age directives (max-age, s-maxage), then behavior directives (no-cache, no-store, must-revalidate, immutable), joined with ', '. This ordering exists only for readability - caches read Cache-Control as an unordered set of directives, so it has no effect on how the header is interpreted. Directives left blank or unchecked are omitted entirely rather than emitted with a default value.

2

Numeric field validation

max-age and s-maxage accept only non-negative whole seconds; decimals, negative numbers, and non-numeric text are rejected before the header is built. Selecting no-store alongside max-age, s-maxage, or immutable is flagged, since no-store instructs caches to skip storage entirely, making any freshness directive on the same header meaningless.

Good uses

  • Setting a long max-age plus immutable for fingerprinted build assets like app.a1b2c3.js so browsers skip revalidation on an ordinary reload while the cached response is still fresh; a new request still happens once the entry expires, is evicted, or the user forces a reload
  • Splitting max-age (browser) from s-maxage (CDN) so a page can be cached longer at the edge than in the visitor's own browser
  • Producing a no-store header for an authenticated API response or a page containing personal data that must never be written to any cache

Limits and checks

  • The generator only produces the header string - it does not verify your server, CDN, or framework actually sends it; confirm with curl -I or browser devtools network tab
  • immutable is honored mainly for skip-revalidation-on-reload behavior in some browsers; many CDNs and proxies ignore it, so don't rely on it to control shared-cache duration
  • no-cache still permits storage - it forces revalidation on every use, it does not prevent caching, which is the opposite of what the name suggests

Common questions

What's the actual difference between no-cache and no-store?

no-cache allows a cache to store the response but requires it to revalidate with the origin server before serving it again, typically via a conditional request. no-store forbids storing the response at all, in any cache, at any point. Use no-store for genuinely sensitive responses, no-cache when you just want freshness guaranteed.

If I set s-maxage, does that also control how long the browser caches the page?

No. Per the caching specification, private browser caches ignore s-maxage; they use max-age when it is present, otherwise an applicable Expires header when one is present, and only fall back to heuristic freshness when neither is present. Set max-age explicitly if you need defined browser-side caching behavior alongside a separate s-maxage for shared caches.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools