Cache-Control Builder

Build HTTP Cache-Control headers visually and inspect TTL directives.

Environment Presets

Directives configuration

no-storeNever store response in any cache. Overrides other directives.

no-cacheMust revalidate stale responses with the origin server before serving.

publicAllows responses to be stored by shared caches (CDNs, edge proxies).

privateResponse is user-specific. Block shared caches/CDNs from storing.

must-revalidateOnce stale, cache cannot serve response without server confirmation.

proxy-revalidateLike must-revalidate but strictly applies to shared/proxy caches.

immutableResponse body is immutable. Never validate with server within max-age.

max-age

s-maxage

stale-while-revalidate

stale-if-error

Directives Count2 directives

Cache ScopePublic

Max-Age TTL1d

RevalidationNo

Live Preview

Full HTTP Header

Cache-Control: public, max-age=86400

Value Only

public, max-age=86400

Example HTTP Response

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=86400

Cache-Control Builder — generate HTTP cache directives interactively

The Cache-Control HTTP header controls how browsers, CDNs, and proxy caches store your responses. The most common directives are max-age (how long in seconds a cached response is fresh), no-store (never cache at all — for sensitive data), and no-cache (always revalidate before serving). Use public to allow CDN caching and private for user-specific responses. The immutable directive is ideal for content-hashed static assets — it prevents browsers from issuing conditional revalidation requests during the max-age window, giving you the fastest possible cache performance.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Building a Cache-Control header with the directives you actually intend.
Getting the immutable and stale-while-revalidate syntax right.
Producing different headers for hashed assets and HTML.
Comparing a no-store against a no-cache policy.
Checking a header a server is emitting against what you meant.

Frequently Asked Questions

What is the difference between no-cache and no-store?: `no-cache` permits storage but requires revalidation before reuse. `no-store` forbids storing the response at all. The names are misleading — `no-cache` is what you want for a page that changes often, `no-store` for a response containing sensitive data.
What does immutable actually do?: Tells the browser not to revalidate even on a manual reload. It is only correct for content-hashed assets whose URL changes when the content does, which is exactly the case bundlers produce — and disastrous on anything served from a stable URL.
What is stale-while-revalidate for?: Serving the cached response immediately while fetching a fresh one in the background. It removes the latency cost of revalidation, which is why it suits content where being a few seconds out of date is acceptable and waiting is not.
When should a response be private rather than public?: Whenever it is user-specific. `private` allows the browser to cache but forbids shared caches and CDNs from doing so — and getting this wrong is how one user's personalised page is served to another, which is a genuine and recurring incident class.
Do ETag and Cache-Control conflict?: No, they work together. `Cache-Control` decides how long the response is fresh; the ETag decides what happens afterwards, letting the server answer 304 with no body. Freshness avoids the request entirely, and validation makes the unavoidable one cheap.

Common errors and gotchas

Confusing `no-cache` with `no-store` — the first allows caching with revalidation, the second forbids it.
Setting a long max-age on a file whose name has no hash, which then cannot be updated.
Using `immutable` on something that changes, which caches it past any fix.
Forgetting that a CDN and a browser can be given different lifetimes via s-maxage.
Setting private on a response a CDN needs to cache, or public on one it must not.