localStorage vs sessionStorage

sessionStorage is scoped to the current browser tab and session. Data survives page refreshes within the same tab but is cleared when the tab closes. Two tabs to the same site have separate, isolated sessionStorage — they do not share data.

Both storages share the same API: setItem(key, value), getItem(key), removeItem(key), clear(), and length property. The same code works for both — just replace localStorage with sessionStorage and vice versa.

Use localStorage for: user preferences (theme, language), cached API responses, remember-me functionality. Use sessionStorage for: wizard/form step state, temporary shopping cart before checkout, data that should not persist across visits for privacy reasons.

Both storages are strictly origin-scoped (protocol + host + port). https://example.com cannot read localStorage set by http://example.com. This is a security boundary — subdomains are also separate origins unless document.domain is manipulated (deprecated).

Both have ~5MB per origin limit in most browsers. Exceeding the limit throws a QuotaExceededError. Large data storage needs require IndexedDB which supports gigabytes of structured data. Web Storage is for small key-value pairs, not binary blobs or large datasets.

Web Storage reads and writes are synchronous and block the main thread. For large reads or writes, this can cause jank. Prefer IndexedDB for frequent large data operations. Keep Web Storage values small and infrequent to avoid performance issues.

Web Storage stores only strings. Serialize objects with JSON.stringify(); deserialize with JSON.parse(). Handle parse failures: try { return JSON.parse(stored) } catch { return defaultValue }. Corrupt or non-JSON values in storage throw parse errors.

localStorage in private/incognito mode is cleared when all private windows are closed — behaving like sessionStorage. Code relying on localStorage for authentication state should handle the case where localStorage is wiped unexpectedly.

Browsers increasingly restrict third-party storage access. An iframe from third-party.com on first-party.com cannot access third-party.com's localStorage. Safari's ITP and Firefox's Enhanced Tracking Protection partition storage — first-party usage is unaffected.

localStorage persists indefinitely until cleared programmatically or by the user; sessionStorage clears when the tab closes. Both are origin-scoped, synchronous string key-value stores with ~5MB capacity. Use localStorage for preferences and persistent state; use sessionStorage for temporary, session-scoped state that should not survive tab close.