no-cache does not mean do not cache. Seven of seventeen reach a CDN.

The header

Sent on a

Cache-Control value

Add or remove a directive

What this header says

Nothing here addresses a shared cache. Only the visitor's own browser is being instructed.

no-cache is present, so a stored copy must be revalidated before it is reused.

Note that no-cache does NOT prevent storage. The response is still stored; it just cannot be served without checking with you first. The directive that forbids storing is no-store.

Every directive here is valid for this side of the exchange.

What the specification defines

directives: 17
mention a shared cache: 7
mention both kinds: 2
have an optional value: 3

RFC 9111 separates a shared cache — a CDN, a reverse proxy, anything serving more than one person — from a private one, which is the browser's. Seven of the seventeen directives name a shared cache in their own definitions, and only two name both. IANA's registry of these directives records none of that: it carries names and references and nothing about behaviour, which is why this page reads the specification's prose instead.

Seven directives take a value, but only four require one. no-cache, private and max-stale each have a valid form with no value at all, and for no-cache the two forms mean different things: with a field name it restricts only that header, without one it applies to the whole response.

All 17 directives

Showing 17 / 17

Directive	Sent on	Value	Shared cache	RFC 9111 says
max-age	Request	Required	No	5.2.1.1 The max-age request directive indicates that the client prefers a response whose age is less than or equal to the specified number of seconds. Unless the max-stale request directive is also present, the client does not wish to receive a stale response.
max-stale	Request	Optional	No	5.2.1.2 The max-stale request directive indicates that the client will accept a response that has exceeded its freshness lifetime. If a value is present, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds.
min-fresh	Request	Required	No	5.2.1.3 The min-fresh request directive indicates that the client prefers a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
no-cache	Request	None	No	5.2.1.4 The no-cache request directive indicates that the client prefers a stored response not be used to satisfy the request without successful validation on the origin server.
no-store	Request	None	Yes	5.2.1.5 The no-store request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches.
no-transform	Request	None	No	5.2.1.6 The no-transform request directive indicates that the client is asking for intermediaries to avoid transforming the content, as defined in Section 7.7 of [HTTP].
only-if-cached	Request	None	No	5.2.1.7 The only-if-cached request directive indicates that the client only wishes to obtain a stored response. Caches that honor this request directive SHOULD, upon receiving it, respond with either a stored response consistent with the other constraints of the request or a 504 (Gateway Timeout) status code. 5.2.2.
max-age	Response	Required	No	5.2.2.1 The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds. This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the quoted-string form.
must-revalidate	Response	None	Yes	5.2.2.2 The must-revalidate response directive indicates that once the response has become stale, a cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3.
must-understand	Response	None	No	5.2.2.3 The must-understand response directive limits caching of the response to a cache that understands and conforms to the requirements for that response's status code. A response that contains the must-understand directive SHOULD also contain the no-store directive.
no-cache	Response	Optional	No	5.2.2.4 The no-cache response directive, in its unqualified form (without an argument), indicates that the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see Section 4.3.
no-store	Response	None	Yes	5.2.2.5 The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or the response and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.
no-transform	Response	None	No	5.2.2.6 The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the content, as defined in Section 7.7 of [HTTP].
private	Response	Optional	Yes	5.2.2.7 The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).
proxy-revalidate	Response	None	Yes	5.2.2.8 The proxy-revalidate response directive indicates that once the response has become stale, a shared cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3.
public	Response	None	Yes	5.2.2.9 The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable.
s-maxage	Response	Required	Yes	5.2.2.10 The s-maxage response directive indicates that, for a shared cache, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field.

Every definition below is quoted verbatim from RFC 9111 section 5.2, with its section number. Nothing is uploaded — the parsing happens in this tab. Snapshot taken 2026-08-03

Also available in: Español · Português · Français · العربية

Cache-Control header: every directive, and what a CDN sees

Pick directives and get a header, or paste one and find out what it actually tells a browser and a shared cache.

What is the Cache-Control header?

Cache-Control is how a server tells caches what they may do with a response, and how a client tells them what it will accept. RFC 9111 defines seventeen directives for it: seven that belong on a request and ten that belong on a response. Four names appear on both sides — max-age, no-cache, no-store and no-transform — and mean different things depending on which way the message is travelling.

The distinction that matters most is not in the directive list at all. RFC 9111 separates a shared cache, meaning a CDN or a reverse proxy or anything serving more than one person, from a private cache, which is the browser's own. Seven of the seventeen directives name a shared cache in their definitions and only two name both kinds. IANA keeps a registry of these directives, and it records none of that — names and references and nothing about behaviour — so this page reads the specification's prose instead.

That is why a header can look thorough and still say nothing to your CDN. max-age speaks to any cache; s-maxage, public, private and proxy-revalidate are the ones that single out the shared one.

How to use it

Choose the side. Response is the usual case — what your server sends. Request is what a browser or a client sends, and it has a different set of seven directives.
Click directives or type the header directly. The buttons and the text field are the same thing; toggling a directive rewrites the field, and editing the field updates the buttons.
Read the verdict, not just the string. You get told whether anything here reaches a shared cache, what is actually being forbidden, and which directives have problems — with the specification's own wording for each one below.

no-cache does not mean do not cache

This is the most consequential misreading in the whole header, and RFC 9111 settles it plainly. The response form of no-cache means the response "MUST NOT be used to satisfy any other request without forwarding it for validation". The response is still stored. It simply cannot be handed out again without checking with your server first, which is usually exactly what people want and not at all what they think they are asking for.

The directive that forbids storing is no-store: a cache "MUST NOT store any part of" the request or response. If you have sensitive data and you reached for no-cache, you reached for the wrong one. This page reports the two as separate findings rather than folding them together, and says so on the spot when a header has no-cache without no-store.

A related subtlety worth knowing: no-cache can take a field name as a value, and the two forms differ. Unqualified, it applies to the whole response. With a field name, it restricts only that header while the rest of the response may still be reused. Seven directives take a value at all, and only four of them require one — no-cache, private and max-stale each have a perfectly valid form with nothing after them.

What this page will not tell you

It will not tell you what your particular CDN does. Directives are what the specification says a conforming cache must and may do; every commercial CDN layers its own configuration, its own vendor directives and its own defaults on top, and several of them honour non-standard extensions this page does not know about. A directive marked as reaching a shared cache tells you the standard addresses it, not that your provider implements it the way you expect.

It also covers Cache-Control only. Freshness is decided by other headers too — Expires, Age, ETag and Last-Modified all take part, and a response with no Cache-Control at all can still be cached by heuristic. Checking one header is a necessary step and not a complete audit.

And it reports the specification's own words rather than advice. There is no recommended header here, because the right one depends on whether the resource is personalised, whether it is versioned in its URL, and how quickly you need a change to reach people. What the page can do is make sure the header you chose means what you think it does.

Why is it free?

The directive table is a few kilobytes travelling with the page, and the parsing happens in your own browser. Nothing you type is uploaded, nothing is logged, and there is no account to create.

No sign-up, no limits, and no watermark on anything you copy.