no-cache não significa “não armazene”. Sete das dezessete chegam à CDN.

O cabeçalho

Enviado numa

Valor do Cache-Control

Adicione ou remova uma diretiva

O que este cabeçalho diz

Nada aqui se dirige a um cache compartilhado. Só o navegador do visitante está sendo instruído.

Há no-cache, então uma cópia armazenada precisa ser revalidada antes de ser reusada.

Atenção: no-cache NÃO impede o armazenamento. A resposta continua guardada; ela só não pode ser servida sem consultar você antes. A diretiva que proíbe armazenar é no-store.

Todas as diretivas aqui valem para este lado da troca.

O que a especificação define

diretivas: 17
mencionam um cache compartilhado: 7
mencionam os dois tipos: 2
têm valor opcional: 3

A RFC 9111 separa o cache compartilhado — uma CDN, um proxy reverso, qualquer coisa que sirva a mais de uma pessoa — do privado, que é o do navegador. Sete das dezessete diretivas citam um cache compartilhado na própria definição e só duas citam os dois. O registro da IANA dessas diretivas não guarda nada disso: traz nomes e referências e nada sobre comportamento, e é por isso que esta página lê a prosa da especificação.

Sete diretivas levam valor, mas só quatro o exigem. no-cache, private e max-stale têm uma forma válida sem valor algum, e no caso do no-cache as duas formas significam coisas diferentes: com um nome de cabeçalho ela restringe só aquele cabeçalho; sem ele vale para a resposta inteira.

As 17 diretivas

Buscar

Mostrando 17 / 17

Diretiva	Enviada em	Valor	Cache compartilhado	A RFC 9111 diz
max-age	Requisição	Obrigatório	Não	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	Requisição	Opcional	Não	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	Requisição	Obrigatório	Não	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	Requisição	Nenhum	Não	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	Requisição	Nenhum	Sim	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	Requisição	Nenhum	Não	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	Requisição	Nenhum	Não	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	Resposta	Obrigatório	Não	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	Resposta	Nenhum	Sim	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	Resposta	Nenhum	Não	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	Resposta	Opcional	Não	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	Resposta	Nenhum	Sim	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	Resposta	Nenhum	Não	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	Resposta	Opcional	Sim	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	Resposta	Nenhum	Sim	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	Resposta	Nenhum	Sim	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	Resposta	Obrigatório	Sim	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.

Cada definição abaixo é citada literalmente da RFC 9111, seção 5.2, com o número da seção. Nada é enviado — a análise acontece nesta aba. Retrato tirado em 2026-08-03

Também disponível em: English · Español · Français · العربية

Cabeçalho Cache-Control: todas as diretivas e o que a CDN vê

Escolha diretivas e receba um cabeçalho, ou cole um e descubra o que ele realmente diz a um navegador e a um cache compartilhado.

O que é o cabeçalho Cache-Control?

Cache-Control é como um servidor diz aos caches o que podem fazer com uma resposta, e como um cliente diz a eles o que vai aceitar. A RFC 9111 define dezessete diretivas: sete que vão numa requisição e dez que vão numa resposta. Quatro nomes aparecem nos dois lados — max-age, no-cache, no-store e no-transform — e significam coisas diferentes conforme a direção em que a mensagem viaja.

A distinção que mais importa nem está na lista de diretivas. A RFC 9111 separa o cache compartilhado, ou seja uma CDN ou um proxy reverso ou qualquer coisa que sirva a mais de uma pessoa, do cache privado, que é o do navegador. Sete das dezessete diretivas citam um cache compartilhado na definição e só duas citam os dois. A IANA mantém um registro dessas diretivas e não guarda nada disso: nomes e referências e nada sobre comportamento, então esta página lê a prosa da especificação.

É por isso que um cabeçalho pode parecer caprichado e não dizer nada à sua CDN. max-age fala com qualquer cache; s-maxage, public, private e proxy-revalidate são as que apontam expressamente para o compartilhado.

Como usar

Escolha o lado. Resposta é o caso comum: o que o seu servidor envia. Requisição é o que um navegador ou cliente envia, e tem outro conjunto de sete diretivas.
Clique nas diretivas ou digite o cabeçalho direto. Os botões e o campo de texto são a mesma coisa: alternar uma diretiva reescreve o campo, e editar o campo atualiza os botões.
Leia o veredito, não só a string. Você fica sabendo se algo ali chega a um cache compartilhado, o que está de fato sendo proibido e quais diretivas têm problemas, com a redação original da especificação logo abaixo.

no-cache não significa “não armazene”

É a leitura equivocada de maior consequência no cabeçalho inteiro, e a RFC 9111 resolve isso sem rodeios. A forma de resposta do no-cache significa que a resposta “não deve ser usada para satisfazer nenhuma outra requisição sem ser encaminhada para validação”. A resposta continua armazenada. Ela só não pode ser entregue de novo sem consultar o seu servidor antes — o que costuma ser exatamente o que as pessoas querem e nada do que acham que estão pedindo.

A diretiva que proíbe armazenar é no-store: um cache “não deve armazenar nenhuma parte” da requisição nem da resposta. Se você tem dados sensíveis e recorreu ao no-cache, recorreu à errada. Esta página relata as duas como achados separados em vez de misturá-las, e avisa na hora quando um cabeçalho traz no-cache sem no-store.

Uma sutileza relacionada que vale conhecer: no-cache pode levar um nome de cabeçalho como valor, e as duas formas diferem. Sem valor, vale para a resposta inteira. Com um nome de cabeçalho, restringe só aquele, enquanto o resto da resposta ainda pode ser reusado. Sete diretivas levam valor e só quatro o exigem: no-cache, private e max-stale têm uma forma perfeitamente válida sem nada depois.

O que esta página não vai lhe dizer

Ela não vai dizer o que a sua CDN específica faz. As diretivas são o que a especificação diz que um cache conforme deve e pode fazer; toda CDN comercial acrescenta por cima a própria configuração, as próprias diretivas proprietárias e os próprios padrões, e várias honram extensões não padronizadas que esta página desconhece. Uma diretiva marcada como alcançando um cache compartilhado diz que o padrão se dirige a ele, não que o seu provedor a implemente como você espera.

Ela também cobre apenas o Cache-Control. O frescor é decidido por outros cabeçalhos também — Expires, Age, ETag e Last-Modified participam todos —, e uma resposta sem Cache-Control nenhum ainda pode ser armazenada por heurística. Conferir um cabeçalho é um passo necessário, não uma auditoria completa.

E ela apresenta as palavras da especificação, não conselhos. Não há um cabeçalho recomendado aqui, porque o certo depende de o recurso ser personalizado, de a URL dele ser versionada e da rapidez com que você precisa que uma mudança chegue às pessoas. O que a página consegue fazer é garantir que o cabeçalho escolhido significa o que você pensa.

Por que é grátis?

A tabela de diretivas são alguns kilobytes que viajam com a página, e a análise acontece no seu próprio navegador. Nada do que você digita é enviado, nada é registrado e não há conta a criar.

Sem cadastro, sem limites e sem marca d'água em nada que você copiar.