Cache-Control Header Builder

Composes a valid Cache-Control header following RFC 9111. Tick the directives you need (no-cache, no-store, immutable, …), set the freshness windows (max-age, s-maxage, stale-while-revalidate, stale-if-error), and copy the resulting header. Includes four presets covering the most common deployment patterns: immutable static asset, private rendered page, public API response with stale serving, and full no-store.

The directive people get wrong is no-cache, which does not mean do not cache. It means the response may be stored but must be revalidated with the origin before it is reused, so a cache still keeps a copy and a conditional request can still answer 304. The directive that actually forbids storage is no-store. Pairing them is common and harmless, but reaching for no-cache when you meant no-store leaves the response sitting in caches you did not intend.

Freshness is counted from when the origin generated the response, not from when your visitor received it. A shared cache reports how far along that clock it is in the Age header, so a response with max-age=600 that spent 500 seconds in a CDN arrives with 100 seconds of life left. s-maxage overrides max-age for shared caches only, which is how you keep a long CDN lifetime while browsers revalidate sooner.

immutable earns its place in one narrow case: it tells the browser not to revalidate even when the user presses reload, which is the one action that otherwise ignores a long max-age. It is only safe on a URL whose content can never change, which in practice means a filename with a content hash in it.

What a header cannot do is reach responses that are already cached. Shortening max-age today does nothing about copies handed out yesterday under the old value, and they stay fresh until their original window expires. That asymmetry is the reason static assets are versioned by URL rather than by header.