FreeToGenerate.com

no-cache no significa «no almacenes». Siete de diecisiete llegan a una CDN.

La cabecera

Qué dice esta cabecera

Nada de aquí se dirige a una caché compartida. Solo se está dando instrucciones al navegador del visitante.

Está no-cache, así que una copia almacenada debe revalidarse antes de volver a usarse.

Ojo: no-cache NO impide el almacenamiento. La respuesta se sigue guardando; simplemente no puede servirse sin consultarte antes. La directiva que prohíbe almacenar es no-store.

Todas las directivas de aquí valen para este lado del intercambio.

Lo que define la especificación

directivas
17
mencionan una caché compartida
7
mencionan los dos tipos
2
tienen valor opcional
3

El RFC 9111 separa la caché compartida —una CDN, un proxy inverso, cualquier cosa que sirva a más de una persona— de la privada, que es la del navegador. Siete de las diecisiete directivas nombran una caché compartida en su propia definición y solo dos nombran las dos. El registro de IANA de estas directivas no recoge nada de eso: trae nombres y referencias y nada sobre comportamiento, y por eso esta página lee la prosa de la especificación.

Siete directivas llevan valor, pero solo cuatro lo exigen. no-cache, private y max-stale tienen una forma válida sin valor alguno, y en el caso de no-cache las dos formas significan cosas distintas: con un nombre de cabecera restringe solo esa cabecera; sin él se aplica a toda la respuesta.

Las 17 directivas

Mostrando 17 / 17

DirectivaSe envía enValorCaché compartidaEl RFC 9111 dice
max-agePeticiónObligatorioNo5.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-stalePeticiónOpcionalNo5.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-freshPeticiónObligatorioNo5.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-cachePeticiónNingunoNo5.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-storePeticiónNingunoSí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-transformPeticiónNingunoNo5.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-cachedPeticiónNingunoNo5.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-ageRespuestaObligatorioNo5.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-revalidateRespuestaNingunoSí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-understandRespuestaNingunoNo5.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-cacheRespuestaOpcionalNo5.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-storeRespuestaNingunoSí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-transformRespuestaNingunoNo5.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].
privateRespuestaOpcionalSí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-revalidateRespuestaNingunoSí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.
publicRespuestaNingunoSí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-maxageRespuestaObligatorioSí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 definición de abajo está citada literalmente del RFC 9111, apartado 5.2, con su número de sección. No se sube nada: el análisis ocurre en esta pestaña. Instantánea tomada el 2026-08-03

También disponible en: English · Português · Français · العربية

Cabecera Cache-Control: todas las directivas y qué ve una CDN

Elige directivas y obtén una cabecera, o pega una y descubre qué le dice de verdad a un navegador y a una caché compartida.

¿Qué es la cabecera Cache-Control?

Cache-Control es la forma que tiene un servidor de decirle a las cachés qué pueden hacer con una respuesta, y la que tiene un cliente de decirles qué aceptará. El RFC 9111 define diecisiete directivas: siete que van en una petición y diez que van en una respuesta. Cuatro nombres aparecen en los dos lados —max-age, no-cache, no-store y no-transform— y significan cosas distintas según en qué dirección viaje el mensaje.

La distinción que más importa no está en la lista de directivas. El RFC 9111 separa la caché compartida, es decir una CDN o un proxy inverso o cualquier cosa que sirva a más de una persona, de la caché privada, que es la del navegador. Siete de las diecisiete directivas nombran una caché compartida en su definición y solo dos nombran las dos. IANA mantiene un registro de estas directivas y no recoge nada de eso: nombres y referencias y nada sobre comportamiento, así que esta página lee la prosa de la especificación.

Por eso una cabecera puede parecer minuciosa y no decirle nada a tu CDN. max-age se dirige a cualquier caché; s-maxage, public, private y proxy-revalidate son las que señalan expresamente a la compartida.

Cómo usarla

  1. Elige el lado. Respuesta es el caso habitual: lo que envía tu servidor. Petición es lo que envía un navegador o un cliente, y tiene otro conjunto de siete directivas.
  2. Pulsa directivas o escribe la cabecera directamente. Los botones y el campo de texto son lo mismo: activar una directiva reescribe el campo, y editar el campo actualiza los botones.
  3. Lee el veredicto, no solo la cadena. Se te dice si algo de ahí llega a una caché compartida, qué se está prohibiendo en realidad y qué directivas tienen problemas, con la redacción original de la especificación debajo.

no-cache no significa «no almacenes»

Es la lectura equivocada con más consecuencias de toda la cabecera, y el RFC 9111 la zanja sin rodeos. La forma de respuesta de no-cache significa que la respuesta «no debe usarse para satisfacer ninguna otra petición sin reenviarla para su validación». La respuesta se sigue almacenando. Sencillamente no puede volver a entregarse sin consultar antes a tu servidor, que suele ser justo lo que la gente quiere y en absoluto lo que cree estar pidiendo.

La directiva que prohíbe almacenar es no-store: una caché «no debe almacenar ninguna parte» de la petición ni de la respuesta. Si tienes datos sensibles y recurriste a no-cache, recurriste a la equivocada. Esta página informa de las dos como hallazgos separados en vez de mezclarlas, y lo advierte en el momento cuando una cabecera lleva no-cache sin no-store.

Un matiz relacionado que conviene conocer: no-cache puede llevar un nombre de cabecera como valor, y las dos formas difieren. Sin valor se aplica a toda la respuesta. Con un nombre de cabecera restringe solo esa, mientras el resto de la respuesta puede seguir reutilizándose. Siete directivas llevan valor y solo cuatro lo exigen: no-cache, private y max-stale tienen una forma perfectamente válida sin nada detrás.

Lo que esta página no te va a decir

No te va a decir qué hace tu CDN concreta. Las directivas son lo que la especificación dice que una caché conforme debe y puede hacer; cada CDN comercial añade encima su propia configuración, sus directivas propietarias y sus valores por defecto, y varias respetan extensiones no estándar que esta página desconoce. Que una directiva figure como que llega a una caché compartida te dice que el estándar se dirige a ella, no que tu proveedor la implemente como esperas.

Tampoco cubre más que Cache-Control. La frescura la deciden también otras cabeceras —Expires, Age, ETag y Last-Modified participan todas—, y una respuesta sin Cache-Control puede almacenarse igualmente por heurística. Revisar una cabecera es un paso necesario, no una auditoría completa.

Y expone las palabras de la especificación, no consejos. Aquí no hay una cabecera recomendada, porque la correcta depende de si el recurso es personalizado, de si su URL lleva versión y de con qué rapidez necesitas que un cambio llegue a la gente. Lo que sí puede hacer la página es asegurarse de que la cabecera que elegiste significa lo que crees.

¿Por qué es gratis?

La tabla de directivas son unos pocos kilobytes que viajan con la página, y el análisis ocurre en tu propio navegador. Nada de lo que escribes se sube, no se registra nada y no hay cuenta que crear.

Sin registro, sin límites y sin marca de agua en nada de lo que copies.