HTTP Cache Headers Generator

Cache-Control is an HTTP response header that tells browsers, CDNs, and intermediate proxies how to cache a response. It's the primary caching mechanism in HTTP/1.1 and HTTP/2. Getting it right can dramatically speed up your site (return visitors get assets from cache instead of network), reduce server load, and cut bandwidth costs. Getting it wrong causes stale content being served to users or unnecessary revalidation requests on every page load.

no-cache means 'cache the response, but revalidate with the server before using it.' The browser stores the response and sends a conditional request (If-None-Match or If-Modified-Since) on subsequent visits. If the server returns 304 Not Modified, the cached version is used — no data is transferred. no-store means 'don't store this response anywhere, ever.' Nothing is saved to disk or memory. Every request fetches a fresh copy from the server. Use no-store for sensitive data (bank balances, private user data). Use no-cache for HTML pages that need freshness but benefit from conditional requests.

max-age applies to all caches — browsers and CDNs. s-maxage applies only to shared caches (CDNs, reverse proxies) and overrides max-age for those caches. A browser ignores s-maxage. This lets you set a short browser cache (max-age=0) for HTML pages while letting a CDN cache them for longer (s-maxage=60) with edge-side revalidation. Useful pattern: max-age=0, s-maxage=300 — always fresh in the browser but cached 5 minutes at the CDN edge.

Use immutable only on assets with content-addressed (fingerprinted) filenames — like bundle.abc123.js or main.1f2a3b.css generated by Webpack, Vite, or Parcel. The immutable directive tells the browser: 'don't bother sending a revalidation request during the max-age window, even on explicit refresh.' Combined with max-age=31536000 (1 year), it eliminates all network round-trips for cached assets. Never use immutable on URLs without fingerprinting — if the content changes at the same URL, users will get the old cached version for up to a year.

The Vary header tells caches that the response varies by the specified request header. Vary: Accept-Encoding means the cache should store separate versions for different encodings (gzip, brotli, identity). Without it, a CDN might serve a compressed response to a client that doesn't support compression, or vice versa. Always set Vary: Accept-Encoding if your server serves compressed responses — most CDNs normalize this automatically, but it's required for correctness.

stale-while-revalidate allows a cache to serve a stale response immediately while it revalidates in the background. For example, max-age=60, stale-while-revalidate=120 means: serve the cached version for up to 60 seconds without any network request (fresh window). Between 60-180 seconds old, serve the stale cached version but kick off a background revalidation. After 180 seconds, the cache must wait for a fresh response before serving. This gives you fast responses without staleness — perfect for frequently-updated but not real-time data like news feeds or API responses.