Cache-Control Header Builder generates HTTP Cache-Control response headers with the correct directives for your caching strategy. Select from directives like max-age, s-maxage, no-cache, no-store, must-revalidate, public, private, immutable, and stale-while-revalidate — the builder shows the assembled header value, explains what each directive does, and previews how browsers and CDNs will treat the response.
HTTP caching is one of the most impactful web performance optimizations. A correct Cache-Control header can serve millions of requests without hitting your server. The key directives: max-age=N tells the browser to cache the response for N seconds. public allows CDN caching. private restricts caching to the end user's browser only. no-cache requires the cache to revalidate with the server before serving (despite the name, it does cache). no-store prohibits caching entirely. immutable tells browsers the resource will never change (used with content-hashed URLs).
A common optimal strategy for static assets: Cache-Control: public, max-age=31536000, immutable (1 year, immutable) with content-hashed filenames (app.a1b2c3.js). For HTML pages: Cache-Control: no-cache (the browser caches but always revalidates, using ETags for 304 responses to avoid re-downloading unchanged content). For sensitive pages: Cache-Control: no-store, private.
Static assets with content hashing
Result: Cache-Control: public, max-age=31536000, immutable — never re-downloaded once cached
HTML pages
Result: Cache-Control: no-cache — cached but always revalidated; 304 responses avoid re-download
Private user data
Result: Cache-Control: no-store, private — never cached by any intermediate
What is the difference between no-cache and no-store?
no-cache: the response MAY be cached, but the cache must revalidate with the origin server before serving it. If the server returns 304 Not Modified (using ETags), the cached copy is served without re-downloading the full response. no-store: the response MUST NOT be stored by any cache. Every request goes to the origin server. Use no-store for highly sensitive data (bank statements, medical records). Use no-cache for frequently-changing pages where you still want to use 304 optimization.
What is s-maxage and when do I use it?
s-maxage specifies the max age for shared caches (CDNs like Cloudflare, Fastly, Varnish) separately from the browser cache (max-age). Example: Cache-Control: public, max-age=300, s-maxage=86400 — browsers cache for 5 minutes, CDN caches for 1 day. This is useful when your CDN has purge capability (you can invalidate the CDN manually after deploys) but browsers cannot be purged.
What is stale-while-revalidate?
stale-while-revalidate=N allows a cache to serve a stale response while it fetches a fresh one in the background. Example: Cache-Control: max-age=60, stale-while-revalidate=600 — after 60 seconds, the cache serves the stale response immediately (no latency) while fetching fresh content. After 660 seconds, the cache must block on a fresh fetch. This pattern dramatically reduces perceived latency for frequently-updated content.
What is ETag and how does it work with no-cache?
ETag (entity tag) is a unique identifier for a specific version of a resource, like a hash of the content. When a browser has a cached response with an ETag, it sends If-None-Match: {etag} in the revalidation request. If the content hasn't changed, the server returns 304 Not Modified with no body — saving bandwidth. ETags work best with no-cache (always revalidate) since the cache must check every time.
What is Cache-Control: immutable?
immutable tells browsers that the response will never change during the max-age window — the browser should not send conditional revalidation requests even when the user reloads the page. Without immutable, a browser reload sends a conditional request even for cached resources. With immutable, the cached resource is served unconditionally. Always pair immutable with content-hashed URLs (app.abc123.js) to ensure different content gets a different URL.