Tamaño, caducidad, acceso y ley en almacenamiento local vs cookies

¿Cuál es la diferencia entre el almacenamiento local y las cookies?

La diferencia central en almacenamiento local vs cookies es adónde van los datos: el navegador adjunta las cookies a las peticiones HTTP que envía al servidor, mientras que el almacenamiento local se queda dentro del navegador hasta que un script lo lee y lo manda a algún sitio. Todo lo demás se deriva de eso. El WHATWG HTML Standard, que define localStorage, dice que se creó para datos que las cookies manejan mal, "because they are transmitted with every request."

Propiedad	Cookies	Almacenamiento local
Definido en	RFC 6265, en proceso de sustitución por draft-ietf-httpbis-rfc6265bis	WHATWG HTML Standard, sección 12
Tamaño	Al menos 4096 bytes por cookie (mínimo de RFC 6265)	5 MiB por origen (MDN)
Caducidad	Expires o Max-Age, o fin de la sesión	Ninguna; permanece hasta que se borra
Se envía al servidor	Sí, en la cabecera Cookie de las peticiones que coinciden	Nunca, salvo que un script lo envíe
Legible por JavaScript	Sí, mediante document.cookie, salvo con HttpOnly	Siempre, por cualquier script del origen
Atributos de seguridad	HttpOnly, Secure, SameSite, Domain, Path	Ninguno
Ámbito	Dominio y ruta; sin aislamiento por puerto	Origen: esquema, host y puerto
Safari ITP	Las cookies creadas con document.cookie tienen un tope de 7 días	Se borra tras 7 días de uso de Safari sin interacción
Artículo 5(3) de ePrivacy	Cubiertas	Cubierto

¿Cuántos datos caben en una cookie y en el almacenamiento local?

Una cookie admite unos 4 KB y el almacenamiento local unos 5 MiB por origen, una diferencia de más de mil veces. La cifra de la cookie viene de RFC 6265, sección 6.1, que fija un suelo, no un techo: los user agents "SHOULD provide" al menos "4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", al menos "50 cookies per domain" y al menos "3000 cookies total".

El borrador que lo sustituye cambia la naturaleza de ese número. En draft-ietf-httpbis-rfc6265bis-22, fechado en diciembre de 2025 y que el datatracker del IETF lista como Internet-Draft activo en camino a Proposed Standard, el navegador debe "ignore the cookie entirely" si "the sum of the lengths of cookie-name and cookie-value is more than 4096 octets", y cada valor de atributo se limita a 1024 octetos. El mínimo que había que admitir se ha convertido en un máximo estricto. La historia de esa cifra está en el artículo sobre el límite de tamaño de las cookies.

El HTML Standard no fija ningún tamaño para el almacenamiento local. Solo dice que setItem() "Throws a QuotaExceededError if the new value couldn't be set." La cifra de trabajo viene de la página de MDN sobre cuotas de almacenamiento: "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin", con Web Storage "limited to 10 MiB of data maximum on all browsers."

Del mínimo al máximo

RFC 6265, la regla actual

• Los user agents deberían ofrecer al menos 4096 bytes por cookie, según la recomendación
• Al menos 50 cookies por dominio
• Al menos 3000 cookies en total
• Un mínimo que el navegador debía alcanzar, no un límite que debía respetar

rfc6265bis-22, el borrador de diciembre de 2025

• El navegador debe ignorar la cookie por completo a partir de 4096 octetos
• Cada valor de atributo limitado a 1024 octetos
• La misma cifra se convierte en un máximo obligatorio

¿Cuándo caducan las cookies y el almacenamiento local?

Una cookie caduca cuando se cumple su fecha Expires o su Max-Age, o al final de la sesión si no tiene ninguno de los dos, mientras que el almacenamiento local no caduca nunca. MDN lo dice sin rodeos: "localStorage data has no expiration time", salvo en la navegación privada, donde los datos se borran al cerrar la última pestaña privada: "cleared when the last 'private' tab is closed." sessionStorage es su hermano de vida corta y se borra cuando termina la sesión de la página.

Las cookies están ganando un límite superior. La sección 5.5 del borrador rfc6265bis dice que un navegador "MUST limit the maximum age of the cookie" y que "the limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future."

El HTML Standard deja el borrado del almacenamiento local en manos del navegador: "User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time." Apple hizo uso de ese permiso.

¿Cuál se envía con cada petición HTTP?

Las cookies se envían con cada petición HTTP que coincide, y el navegador nunca envía el almacenamiento local por su cuenta. RFC 6265 pide a los servidores que mantengan las cookies pequeñas "to minimize network bandwidth due to the Cookie header being included in every request." El borrador añade que "many popular implementations have default limits of 8192 octets" para una cabecera, y que superarlos "could result in requests to the server failing."

"Que coincide" significa que la petición encaja con las reglas de dominio, ruta, Secure y SameSite de la cookie. Un valor del almacenamiento local solo llega a un servidor si tu propio script lo lee y lo pone en una petición, en una URL o en un cuerpo.

¿Puede JavaScript leer las cookies y el almacenamiento local?

JavaScript puede leer todos los valores del almacenamiento local de su origen, y todas las cookies salvo las marcadas como HttpOnly. La interfaz Storage del HTML Standard expone exactamente seis miembros: length, key(), getItem(), setItem(), removeItem() y clear(). Ninguno oculta un valor a los scripts, así que cualquier script de la página, incluida una etiqueta de terceros o código inyectado, puede llamar a localStorage.getItem().

Las cookies tienen una forma de excluirse. RFC 6265, sección 4.1.2.6, dice que HttpOnly "instructs the user agent to omit the cookie when providing access to cookies via 'non-HTTP' APIs (such as a web browser API that exposes cookies to scripts)." El anuncio de ITP 2.1 de WebKit, del 21 de febrero de 2019, da la regla práctica: "Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks." El almacenamiento local no tiene forma de cumplir esa regla, y por eso un token de sesión va en una cookie HttpOnly y no en localStorage.

¿Qué hacen los atributos HttpOnly, Secure y SameSite?

Los tres atributos restringen quién lee una cookie y cuándo la envía el navegador, y el almacenamiento local no tiene equivalente para ninguno de ellos.

• HttpOnly oculta la cookie a los scripts, como se cita más arriba. Una cookie creada con document.cookie no puede llevarlo, así que solo la cabecera Set-Cookie de un servidor crea una.
• Secure, según RFC 6265 sección 4.1.2.5, significa que "the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS))."
• SameSite se define en el borrador rfc6265bis, sección 4.1.2.7. Con Strict, "the cookie will only be sent along with 'same-site' requests." Con Lax, también se envía "with 'cross-site' top-level navigations." Con None, va con "same-site and cross-site requests." MDN añade que SameSite=None requiere Secure, y que "some browsers use Lax as the default value if SameSite is not specified."

El ámbito también cambia. El almacenamiento local pertenece a un origen, es decir, al esquema, el host y el puerto juntos. Las cookies son más laxas: RFC 6265 sección 8.5 afirma que "cookies do not provide isolation by port", y el atributo Domain comparte una cookie entre subdominios.

¿Cómo trata Safari el almacenamiento local y las cookies?

Safari borra el almacenamiento local y cualquier otra forma de almacenamiento escribible por scripts tras siete días de uso de Safari sin interacción del usuario con el sitio. WebKit anunció la regla el 24 de marzo de 2020 en "Full Third-Party Cookie Blocking and More", donde señalaba que "APIs like LocalStorage have no expiry function at all." ITP borra "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." La lista incluye IndexedDB, LocalStorage, media keys, SessionStorage, y los registros y la caché de service workers.

El reloj cuenta días de uso de Safari, no días naturales, y las web apps añadidas a la pantalla de inicio llevan su propio contador. Las cookies creadas con document.cookie ya tenían un tope de siete días desde ITP 2.1, en febrero de 2019. Las cookies creadas por el servidor se libran de las dos reglas: la sección de desalojo de MDN afirma que "cookies set by server are exempt from this eviction." Las condiciones que lo activan y la variante de 24 horas se explican en cómo funciona el límite de 7 días de Safari para las cookies.

¿Trata el Derecho de la UE el almacenamiento local de forma distinta a las cookies?

No. El Derecho de la UE trata el almacenamiento local exactamente igual que una cookie, porque el artículo 5(3) de ePrivacy regula el acto de almacenar y leer, no la tecnología. El texto consolidado de la Directiva 2002/58/CE dice:

Los Estados miembros velarán por que únicamente se permita el almacenamiento de información, o la obtención de acceso a la información ya almacenada, en el equipo terminal de un abonado o usuario, a condición de que dicho abonado o usuario haya dado su consentimiento después de que se le haya facilitado información clara y completa, en particular sobre los fines del tratamiento de los datos, con arreglo a lo dispuesto en la Directiva 95/46/CE. Lo anterior no impedirá el posible almacenamiento o acceso de índole técnica al solo fin de efectuar la transmisión de una comunicación a través de una red de comunicaciones electrónicas, o en la medida de lo estrictamente necesario a fin de que el proveedor de un servicio de la sociedad de la información preste un servicio expresamente solicitado por el abonado o el usuario.

La palabra "cookie" no aparece. Las directrices 2/2023 del EDPB sobre el alcance técnico del artículo 5(3), versión 2.0 adoptada el 7 de octubre de 2024, dicen en su apartado 37 que la directiva no fija ningún "upper or lower limit on the length of time that information must persist on a storage medium to be counted as stored, nor is there an upper or lower limit on the amount of information to be stored." El apartado 44 nombra juntos "cookies, local storage, WebSQL". También traza la única línea que los separa en la práctica: un navegador que usa esa información estrictamente dentro del dispositivo no está haciendo "gaining of access" "as long as the information does not leave the device, but when this information or any derivation of this information is accessed, Article 5(3) ePD would apply."

Así que un script que escribe un identificador en localStorage y luego lo envía a un servidor almacena información y accede a ella, y necesita consentimiento salvo que se aplique una excepción. Mover un ID de seguimiento de una cookie al almacenamiento local cambia el comportamiento del navegador y deja la respuesta legal igual, y por eso una herramienta que se presenta como seguimiento sin cookies sigue teniendo que decir qué guarda en el dispositivo. Las excepciones funcionan igual para los dos. Dependen de la finalidad, no de la tecnología, así que un uso que cuenta como "estrictamente necesario" en una cookie cuenta igual, con el mismo razonamiento, en el almacenamiento local, y un uso que necesita consentimiento en una cookie también lo necesita en el almacenamiento local.

Preguntas frecuentes

¿Es el almacenamiento local más seguro que las cookies?

No. Cualquier script del origen puede leer el almacenamiento local, y no tiene nada equivalente a HttpOnly. WebKit aconseja por eso mantener la autenticación en cookies Secure y HttpOnly.

¿El almacenamiento local necesita un banner de cookies?

Necesita el mismo consentimiento que una cookie cuando no es estrictamente necesario. El artículo 5(3) de ePrivacy cubre "el almacenamiento de información" en el dispositivo, sea cual sea la API de almacenamiento.

¿Cuál es el límite de tamaño del almacenamiento local?

MDN da 5 MiB por origen, más 5 MiB de almacenamiento de sesión. El HTML Standard no fija ninguna cifra; setItem() lanza QuotaExceededError cuando falla una escritura.

¿Caduca el almacenamiento local?

No. El almacenamiento local no tiene atributo de caducidad, aunque los navegadores lo borran igualmente: el ITP de Safari tras siete días de uso de Safari sin interacción, y la navegación privada cuando se cierra la última pestaña privada.

¿Puede el servidor leer el almacenamiento local?

No. El navegador nunca envía el almacenamiento local en una petición. El servidor solo ve un valor si un script lo lee y lo envía, mientras que las cookies van en la cabecera Cookie de forma automática.

¿Es sessionStorage distinto de localStorage?

Sí. sessionStorage pertenece a una pestaña y se borra cuando termina esa sesión de la página, mientras que localStorage se comparte entre las pestañas del origen y persiste. Los dos están sujetos a la regla de siete días de Safari.

¿Puede un token de sesión guardarse con seguridad en el almacenamiento local?

Un token de sesión pertenece a una cookie marcada como Secure y HttpOnly, no al almacenamiento local, porque cualquier script del origen puede llamar a localStorage.getItem() y leerlo. El anuncio de ITP 2.1 de WebKit hace la misma observación sobre las cookies de autenticación. El almacenamiento local no tiene ningún atributo que oculte un valor a los scripts.

¿Cuánto puede durar una cookie según el último borrador?

El borrador rfc6265bis limita por primera vez la duración de una cookie: la sección 5.5 exige que el navegador limite la edad máxima de una cookie y recomienda que ese límite no supere los 400 días. El almacenamiento local no tiene una regla así en el HTML Standard, que solo deja el borrado de los datos almacenados a criterio del navegador.

¿Comparten las cookies y el almacenamiento local datos entre subdominios?

Una cookie puede compartirse entre subdominios mediante el atributo Domain, y RFC 6265 señala que las cookies no ofrecen aislamiento por puerto. El almacenamiento local no tiene esa opción: pertenece a un único origen definido por esquema, host y puerto, así que un script en un subdominio no puede leer el almacenamiento local del dominio principal.

¿Qué ocurre con una cookie que supera el límite de 4096 bytes del borrador?

Según draft-ietf-httpbis-rfc6265bis-22, el navegador debe ignorar la cookie por completo en cuanto la suma de su nombre y su valor supera los 4096 octetos. Eso convierte el antiguo mínimo de RFC 6265, un piso que los user agents debían ofrecer como recomendación, en un techo obligatorio. El HTML Standard no fija un límite comparable para el almacenamiento local; setItem() solo lanza QuotaExceededError cuando el nuevo valor no se ha podido guardar.