Cookies, almacenamiento local, caché y huellas del navegador

Estos conceptos suelen aparecer juntos en ajustes de privacidad, instrucciones de depuración y productos de perfiles del navegador. Se comportan de formas lo bastante distintas para que «borra el navegador» sea una instrucción incompleta.

Un modelo mental práctico

Mecanismo	Quién lo crea o controla	Alcance normal	Finalidad habitual	¿Se envía automáticamente con una solicitud?
Cookie HTTP	Un servidor la establece; el navegador la guarda y devuelve según reglas de alcance	Host o dominio, ruta, duración y condiciones de conexión	Identificadores de sesión, preferencias, estado contra abusos	Sí, cuando la solicitud coincide con su alcance
localStorage	JavaScript del sitio	Origen, sujeto a la partición y las políticas del navegador	Estado persistente de la aplicación con pares clave-valor	No
sessionStorage	JavaScript del sitio	Origen dentro de una sesión de navegación de nivel superior	Estado temporal de una pestaña o un flujo	No
Caché HTTP	Navegador y reglas de caché HTTP	Clave de caché, directivas de respuesta, política del navegador	Reutilizar respuestas para reducir latencia y tráfico	Puede satisfacer o revalidar una solicitud
API Cache Storage	JavaScript del sitio o service worker	Origen o partición de almacenamiento	Recursos sin conexión y respuestas administradas por la aplicación	No se adjunta automáticamente; un script controla su uso
Huella del navegador	Un sitio u otro observador mide señales	Depende del observador y de las señales	Seguridad, detección del fraude, analítica o seguimiento	Algunas señales son visibles en las solicitudes; otras necesitan código activo

Las cinco primeras filas implican estado conservado. La última es un método de observación y correlación, aunque el estado conservado también puede ser una de sus entradas.

Cookies: estado dirigido al servidor con reglas de alcance

HTTP carece en gran medida de estado. Las cookies permiten que un servidor entregue al navegador un par nombre-valor y lo reciba en solicitudes posteriores que coincidan. RFC 6265 define el encabezado de respuesta Set-Cookie, el encabezado de solicitud Cookie y el modelo de almacenamiento del navegador.

Una cookie puede ser:

• de sesión, conservada hasta que termina la sesión definida por el navegador;
• persistente, con una fecha de caducidad o duración máxima;
• solo del host, devuelta únicamente al host que la estableció;
• del dominio, aplicable al dominio indicado y a los subdominios que coincidan;
• de una ruta, devuelta solo para rutas de solicitud que coincidan;
• Secure, devuelta únicamente por un canal seguro según lo defina el navegador; y
• HttpOnly, oculta para las API de cookies accesibles mediante scripts, pero disponible en solicitudes HTTP.

Estos atributos afectan al envío y al acceso mediante scripts. No convierten el valor de la cookie en un límite de seguridad independiente. RFC 6265 advierte expresamente de que no debe confiarse en el atributo Path para la seguridad y recomienda un transporte seguro y protección adicional para el contenido sensible de cookies.

Por qué borrar cookies cierra la sesión

Muchos servicios guardan un identificador de sesión aleatorio en una cookie, mientras mantienen en el servidor el registro de la cuenta y los detalles de la sesión. Borrar la cookie elimina la copia del identificador que conserva el navegador, por lo que la siguiente solicitud ya no presenta la misma sesión. La cuenta y otras sesiones del servidor pueden permanecer.

Esto también explica por qué copiar cookies de autenticación es una acción sensible. Un identificador de sesión utilizable puede actuar como una credencial. No pegues cookies sin procesar en incidencias, registros, salidas de automatización ni chats de equipo.

Almacenamiento local: estado controlado por scripts para un origen

El HTML Standard define localStorage como el acceso al área de almacenamiento local de un origen. Está pensado para abarcar varias ventanas y durar más que la sesión actual. El almacenamiento contiene pares clave-valor de cadenas y está disponible para los scripts que se ejecuten con acceso a ese origen.

Un origen suele combinar esquema, host y puerto. Por tanto, estos son alcances de almacenamiento diferentes:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

La ruta de la URL no forma parte del origen. Las páginas /billing/ y /support/ del mismo origen pueden acceder al mismo almacenamiento local, salvo que la aplicación cree su propia separación lógica.

A diferencia de una cookie, una entrada de localStorage no se adjunta automáticamente a las solicitudes HTTP. El script del sitio debe leerla y decidir qué hacer. Esto la hace útil para preferencias de interfaz, borradores y datos de la aplicación, pero cualquier script que se ejecute con la autoridad del origen podría acceder a ella. Los diseños de sesiones sensibles deben tener en cuenta la vulneración de scripts, en vez de suponer que «local» significa secreto.

Persistencia significa aquí que los datos pueden sobrevivir a una sesión de navegación. No implica conservación permanente. Una persona puede borrar los datos, una política del navegador puede restringirlos y el navegador puede aplicar reglas de almacenamiento y expulsión.

sessionStorage tiene otra duración

sessionStorage está asociado al origen y a una sesión de navegación de nivel superior. Resulta adecuado para el estado que debe permanecer mientras continúa el flujo de una pestaña o ventana y terminar con esa sesión. Una pestaña clonada o restaurada puede implicar detalles del ciclo de vida propios del navegador, por lo que las aplicaciones no deben utilizarlo como único registro de trabajo esencial.

El almacenamiento local es solo un mecanismo de datos de sitios

Las aplicaciones web modernas también pueden conservar datos en IndexedDB, Cache Storage, registros de service workers, Origin Private File System, permisos y otros almacenes administrados por el navegador. Por tanto, borrar solo localStorage en las herramientas de desarrollo puede dejar intacto otro estado.

Las indicaciones de privacidad del HTML Standard recomiendan que los navegadores permitan borrar juntos los mecanismos de almacenamiento persistente, porque de lo contrario los sitios podrían utilizar uno para volver a crear un identificador eliminado de otro.

Caché: una palabra para varios mecanismos

La caché HTTP

RFC 9111 define una caché HTTP como un almacén de mensajes de respuesta y el sistema que controla su almacenamiento, recuperación y eliminación. Una caché del navegador puede reutilizar una respuesta vigente o revalidar otra obsoleta, lo que reduce la latencia y la transferencia de red.

La clave de caché incluye al menos el método y el URI de destino de la solicitud, y los encabezados de respuesta influyen en si una respuesta puede reutilizarse y durante cuánto tiempo. La caché HTTP es una capa de optimización. Que una imagen o script esté en caché no suele significar que la persona haya iniciado sesión.

El estado de la caché todavía puede afectar a la privacidad. El tiempo o el hecho de que un recurso ya esté disponible pueden revelar información en algunos modelos de amenazas. Las indicaciones del W3C sobre huellas incluyen la observación de recursos en caché entre las formas de inferir la configuración del navegador o el usuario.

Cache Storage y service workers

La API Cache Storage ofrece a un sitio objetos Cache explícitos y controlados por scripts, a menudo para aplicaciones web sin conexión. La especificación Service Workers indica que estas cachés son distintas de la caché HTTP del navegador, están aisladas por origen y se actualizan o eliminan mediante la lógica de la aplicación, no según las reglas normales de vigencia de HTTP.

Esta diferencia importa durante la depuración:

• borrar «archivos e imágenes almacenados en caché» se dirige a la caché corriente del navegador;
• borrar datos de sitios también puede eliminar Cache Storage y el estado de los service workers; y
• volver a cargar omitiendo la caché HTTP puede dejar un service worker activo que siga controlando las solicitudes.

Identifica qué caché quieres tratar antes de decidir cómo inspeccionarla o borrarla.

La partición del almacenamiento añade otra clave

El alcance por origen permitía que un tercero integrado leyera el mismo almacenamiento cuando aparecía dentro de muchos sitios de nivel superior. Los navegadores modernos añaden cada vez más el sitio de nivel superior o un contexto relacionado a la clave de almacenamiento.

Chrome documenta que su partición del almacenamiento impide que un marco de example.com integrado en a.com comparta automáticamente Local Storage, IndexedDB, Cache Storage, service workers y determinados mecanismos de comunicación con el mismo marco integrado en b.com. Chrome indica que está activada para todos los usuarios desde Chrome 115, con cambios posteriores para algunas API adicionales.

La partición explica un resultado que de otro modo resulta sorprendente: el mismo origen integrado puede ver un almacenamiento distinto según el sitio que lo rodea. No implica que todo el almacenamiento aplique en todas partes un único modelo universal con dos claves. Las versiones del navegador, los contextos de nivel superior e integrados, las concesiones de acceso al almacenamiento, las políticas empresariales, las extensiones y las reglas propias de cada API pueden cambiar el resultado.

Prueba el contexto exacto en vez de deducirlo solo del nombre de dominio.

Huellas del navegador: señales observadas, no una carpeta

El W3C define la creación de huellas del navegador como la capacidad de identificar o reidentificar a un usuario, agente de usuario o dispositivo mediante ajustes de configuración u otras características observables. Sus indicaciones de 2025 distinguen varias formas:

• La creación pasiva de huellas utiliza información ya observable en solicitudes o en la red, como los encabezados y la dirección IP.
• La creación activa de huellas ejecuta código para observar características como el tamaño de la ventana, las fuentes, los dispositivos conectados, el rendimiento, los sensores o el renderizado gráfico.
• La correlación de sucesos transitorios vincula contextos mediante cambios casi simultáneos del dispositivo o el entorno.
• Las técnicas semejantes a cookies guardan y recuperan estado mediante mecanismos que pueden durar más que las cookies corrientes o recrearlas.

Una huella rara vez es un valor inmutable guardado por el navegador. Un observador elige señales, las combina y decide cuánto se parecen a una visita anterior. El resultado puede cambiar al actualizarse el navegador, modificar la ventana, añadir fuentes, conectar un dispositivo o cambiar la ruta de red. También puede seguir siendo similar después de borrar las cookies porque muchas señales subyacentes no han cambiado.

Una huella no demuestra la identidad

Un conjunto de señales puede ser común a muchas personas o variar para una misma persona. Los sitios también pueden combinar una huella con un inicio de sesión, un historial de cuenta en el servidor, la reputación de la red o identificadores almacenados. Que un sitio reconozca el entorno después de borrar datos no demuestra que la huella haya sido la única causa.

Por el mismo motivo, cambiar un ajuste visible no garantiza una identidad nueva. Una configuración coherente y común puede reducir cierta singularidad, mientras que muchos cambios inusuales e independientes pueden formar una combinación más rara. Estas señales no permiten garantizar invisibilidad ni aceptación por terceros.

Qué cambian realmente las acciones habituales de borrado

Acción	Efecto probable	Elementos importantes que permanecen
Borrar las cookies de un sitio	Elimina el estado de cookies correspondiente en el navegador y suele cerrar la sesión de ese perfil	Pueden permanecer los datos de cuenta del servidor, otros dispositivos y almacenes distintos de las cookies
Borrar cookies y otros datos de sitios	Puede eliminar cookies, Web Storage, IndexedDB, service workers y estado relacionado, según la interfaz y el alcance del navegador	El gestor de contraseñas, las descargas, los datos de la cuenta y las señales observables del dispositivo están separados
Borrar archivos e imágenes almacenados en caché	Elimina contenido corriente de respuestas en caché	Las cookies, el almacenamiento local y Cache Storage pueden necesitar una selección independiente
Borrar el historial	Elimina las URL visitadas y las sugerencias relacionadas dentro del alcance seleccionado	Permanecen los archivos descargados y los registros del sitio
Eliminar un perfil del navegador	Elimina del dispositivo sus marcadores, historial, contraseñas y otros ajustes locales	Pueden permanecer los datos sincronizados de la cuenta, archivos descargados o exportados, copias de seguridad y datos del servidor
Iniciar un perfil nuevo	Comienza con otro conjunto de estados del perfil	El dispositivo, el sistema operativo, la compilación del navegador y la red todavía pueden observarse como relacionados

La guía de Chrome sobre datos de navegación trata como categorías distintas el historial, las cookies y otros datos de sitios, los archivos e imágenes en caché, el historial de descargas, Autorrelleno, los ajustes de sitios y los datos de aplicaciones alojadas. También señala que borrar el historial de descargas deja los archivos descargados en el ordenador y que borrar datos con la sesión iniciada puede afectar a la cuenta de Google y a otros dispositivos sincronizados.

El efecto exacto depende del intervalo de tiempo, el perfil, el estado de la cuenta, la versión del navegador y la política empresarial elegidos. Revisa el texto de confirmación antes de borrar datos que puedan resultar difíciles de recuperar.

Cómo afectan los perfiles separados a cada mecanismo

Un perfil persistente correctamente separado debe tener su propio almacén de cookies, áreas de almacenamiento web, bases de datos de sitios, Cache Storage, propiedad de la caché HTTP, historial, permisos de sitios y estado de extensiones. Así se impide que el perfil B herede sin más la sesión almacenada del perfil A.

Varias señales pueden seguir siendo comunes:

• motor y versión del navegador;
• sistema operativo y hardware;
• fuentes instaladas en el sistema y características de la pantalla;
• ajustes de idioma, zona horaria o accesibilidad heredados del host;
• dirección IP y ruta de red cuando no se configura otra ruta; y
• comportamiento del operador o inicios de sesión que vinculan la actividad en la capa de aplicación.

Los distintos perfiles también pueden exponer señales diferentes mediante sus extensiones, permisos, tamaños de ventana, ajustes de idioma o rutas de proxy. El efecto neto depende de la implementación y del contexto. La separación de perfiles debe evaluarse como aislamiento de estado, no como garantía de otra huella.

Diagnostica el síntoma antes de borrarlo todo

«Se ha cerrado mi sesión»

Comprueba primero las cookies. Una cookie de sesión puede haber caducado, haberse eliminado, rechazarse por una política del navegador o haberse invalidado en el servidor. El almacenamiento local puede respaldar la interfaz, pero normalmente no es la cookie que se envía de forma automática para autenticar una solicitud HTTP.

«El sitio ha olvidado mi borrador o los datos sin conexión»

Inspecciona el almacenamiento local, IndexedDB, Cache Storage y el estado de los service workers. Confirma el origen y si la página está en el nivel superior o integrada en otro sitio, porque la partición puede cambiar el almacenamiento disponible.

«La primera recarga es lenta»

Una caché HTTP vacía u obsoleta es un factor probable. La red, el servidor y un service worker pueden causar el mismo síntoma, por lo que debes registrar los tiempos de las solicitudes y el estado de la caché antes de concluir.

«El sitio sigue reconociendo el entorno después de borrar los datos»

Quedan varias explicaciones: la cuenta sigue abierta en otro lugar, el servidor relacionó la visita mediante datos de cuenta o red, sobrevivió otro almacén del navegador o las características observables correlacionaron las sesiones. Trata las huellas como una hipótesis, no como la respuesta automática.

Conclusión orientada a la decisión

Utiliza el mecanismo para elegir la solución:

• inspecciona o borra las cookies cuando la cuestión afecte a las sesiones del servidor;
• inspecciona los almacenes del sitio limitados al origen cuando una aplicación web conserve estado local;
• distingue la caché HTTP de Cache Storage al diagnosticar contenido obsoleto o sin conexión;
• utiliza otro perfil persistente cuando el estado de trabajo almacenado deba permanecer independiente; y
• trata las huellas como correlación entre señales observables, con límites que borrar datos o cambiar un ajuste no pueden eliminar.

Este modelo evita dos errores costosos: borrar más estado del necesario y suponer que un almacén de cookies vacío crea otra identidad de dispositivo.

Limitaciones

El almacenamiento web y el comportamiento de privacidad evolucionan entre navegadores y versiones. Las reglas de cookies de terceros, la partición del almacenamiento, la expulsión, la sincronización, las políticas empresariales, las extensiones y los modos de navegación privada pueden cambiar el comportamiento descrito. La guía explica los estándares y la documentación actual de Chrome en la fecha de consulta; no caracteriza la implementación de todos los navegadores o sitios.