localStorage y sessionStorage: cuándo usar cada uno

Web Storage es una API del navegador para guardar pares de clave y valor asociados a un origen. Sus dos áreas principales son localStorage y sessionStorage, accesibles desde las propiedades homónimas de Window. La API guarda valores de texto y ofrece métodos para leer, escribir, eliminar y contar entradas.

También puede servirte: Qué es JSON y en qué se diferencia de un objeto

localStorage se comparte entre documentos del mismo origen y puede persistir cuando se cierra y se vuelve a abrir el navegador. sessionStorage se separa por origen y por pestaña: una página mantiene sus datos durante la sesión de esa pestaña y los pierde al cerrarla.

El origen incluye esquema, host y puerto. Un documento en https no comparte automáticamente su área con otro en http, con un subdominio diferente o con un puerto distinto. Esa separación ayuda a delimitar el acceso, pero no convierte los datos en secretos frente a un script que ya corre dentro del mismo origen.

Usá localStorage para preferencias que el usuario espera conservar, como tema visual, filtros o el último estado de una interfaz. Usá sessionStorage para datos temporales de un flujo, como un paso de formulario o una selección que no debería aparecer al abrir una pestaña nueva. La decisión depende de la duración y del contexto, no del tamaño.

sessionStorage puede servir para aislar dos pestañas que trabajan con la misma aplicación. localStorage, en cambio, está disponible para otras páginas del mismo origen y puede disparar un evento storage cuando cambia desde otro documento. El evento permite reaccionar a una preferencia compartida, pero no reemplaza la coordinación de una aplicación.

Los valores se convierten en cadenas. Para guardar una estructura hay que serializarla, por ejemplo con JSON.stringify, y comprobar qué ocurre si una versión futura cambia sus campos. No conviene guardar tokens, contraseñas ni información sensible sin analizar el modelo de amenaza: cualquier script del mismo origen puede leer Web Storage.

Las operaciones de Web Storage son sincrónicas: leer o escribir bloquea el hilo de JavaScript mientras termina. Para preferencias pequeñas suele ser suficiente, pero una colección grande puede introducir pausas visibles. Si necesitás datos voluminosos, búsquedas, transacciones o trabajo fuera del hilo principal, compará IndexedDB u otra API pensada para ese caso.

El espacio disponible depende del navegador y del origen. MDN documenta un límite típico de hasta 5 MiB para cada área de localStorage y sessionStorage por origen; al superar la cuota, el navegador puede lanzar QuotaExceededError. La aplicación debe capturar la excepción y definir una salida si el almacenamiento no está disponible.

El modo privado puede cambiar la persistencia y borrar los datos al cerrar la ventana. Además, las políticas de privacidad, bloqueadores y configuraciones del usuario pueden impedir o particionar el acceso. La aplicación debe funcionar aunque no pueda escribir una preferencia y no debe tratar una lectura vacía como prueba de que el usuario nunca guardó nada.

Definí la duración que necesita cada dato: si debe volver al abrir el sitio, localStorage puede encajar; si sólo sirve mientras una pestaña completa un flujo, sessionStorage es más acotado. Confirmá también el origen que leerá el valor y si abrir una segunda pestaña debe verlo.

Guardá sólo valores pequeños y no sensibles, versioná las claves y validá el contenido al leerlo. Envolvé las operaciones en try/catch, manejá QuotaExceededError y ofrecé una ruta que no dependa del almacenamiento. Si el dato cambia en otra pestaña, considerá el evento storage y un estado de interfaz que pueda reconciliarlo.

Antes de elegir Web Storage para una función central, medí el costo de sus operaciones sincrónicas y comparalo con IndexedDB, Cache API o una base remota. La pregunta útil no es cuánto puede guardar el navegador en teoría, sino qué pérdida, exposición o pausa acepta la experiencia concreta.