localStorage frente a sessionStorage

La API Web Storage proporciona dos almacenes de pares clave-valor en el cliente: localStorage (persistente entre sesiones) y sessionStorage (se elimina al cerrar la pestaña). Ambos almacenan valores de tipo cadena y se pueden consultar de forma síncrona mediante JavaScript en el mismo origen.

Los datos de localStorage persisten hasta que el código, el usuario o la eliminación de datos del navegador los borran explícitamente. Sobreviven a los reinicios del navegador, las actualizaciones de la página y el cierre de pestañas. La capacidad suele ser de 5-10 MB por origen, según el navegador.

sessionStorage está limitado a la pestaña y la sesión actuales del navegador. Los datos sobreviven a las actualizaciones de la página dentro de la misma pestaña, pero se eliminan al cerrarla. Dos pestañas del mismo sitio tienen sessionStorage independientes y aislados; no comparten datos.

Ambos almacenamientos comparten la misma API: setItem(key, value), getItem(key), removeItem(key), clear() y la propiedad length. El mismo código funciona con ambos: basta con sustituir localStorage por sessionStorage y viceversa.

Use localStorage para: preferencias del usuario (tema, idioma), respuestas de API en caché y la funcionalidad de recordar la sesión. Use sessionStorage para: el estado de los pasos de asistentes o formularios, un carrito de compra temporal antes del pago y datos que no deban persistir entre visitas por motivos de privacidad.

Ambos almacenamientos están estrictamente limitados al origen (protocolo + host + puerto). https://example.com no puede leer el localStorage establecido por http://example.com. Este es un límite de seguridad; los subdominios también son orígenes separados, a menos que se manipule document.domain (obsoleto).

En la mayoría de los navegadores, ambos tienen un límite de aproximadamente 5 MB por origen. Superar el límite produce un error QuotaExceededError. Para almacenar grandes cantidades de datos se necesita IndexedDB, que admite gigabytes de datos estructurados. Web Storage está pensado para pares clave-valor pequeños, no para blobs binarios ni conjuntos de datos grandes.

Las lecturas y escrituras de Web Storage son síncronas y bloquean el hilo principal. En el caso de lecturas o escrituras grandes, esto puede provocar jank. Prefiera IndexedDB para operaciones frecuentes con grandes volúmenes de datos. Mantenga pequeños y poco frecuentes los valores de Web Storage para evitar problemas de rendimiento.

Web Storage solo almacena cadenas. Serialice los objetos con JSON.stringify() y deserialícelos con JSON.parse(). Gestione los errores de análisis: try { return JSON.parse(stored) } catch { return defaultValue }. Los valores dañados o que no estén en formato JSON producen errores de análisis al almacenarse.

localStorage en modo privado o de incógnito se elimina al cerrar todas las ventanas privadas, por lo que se comporta como sessionStorage. El código que dependa de localStorage para el estado de autenticación debe gestionar el caso en que localStorage se borre inesperadamente.

Los navegadores restringen cada vez más el acceso al almacenamiento de terceros. Un iframe de third-party.com incluido en first-party.com no puede acceder al localStorage de third-party.com. ITP de Safari y Enhanced Tracking Protection de Firefox particionan el almacenamiento; el uso como first-party no se ve afectado.

¿Cuándo se elimina sessionStorage?

localStorage persiste indefinidamente hasta que se borra mediante código o el usuario lo elimina; sessionStorage se borra al cerrar la pestaña. Ambos son almacenes síncronos de pares clave-valor de cadenas, limitados a un origen y con una capacidad aproximada de 5 MB. Use localStorage para preferencias y estados persistentes; use sessionStorage para estados temporales limitados a la sesión que no deban sobrevivir al cierre de la pestaña.