Reading and Writing localStorage in React

localStorage is a built-in browser store with four core methods: setItem(key, value), getItem(key), removeItem(key), and clear(). Data persists across page reloads and browser restarts.

It lives on the window object and is scoped per origin, meaning each domain has its own isolated storage.

Every localStorage call runs synchronously on the main thread. Reading or writing large amounts of data can block rendering and make the UI feel janky.

Because of this, keep stored values small and avoid writing on every keystroke or scroll event.

localStorage can only hold strings. To store an object or array you must serialize it first with JSON.stringify(value) before calling setItem.

If you store a non-string directly, it gets coerced, so an object becomes the useless string [object Object].

When reading, you call JSON.parse(localStorage.getItem(key)), but parsing can throw if the stored string is corrupted or was written by another source.

Wrap the parse in a try/catch and fall back to a default value so a bad entry does not crash your component.

localStorage is not always usable: during server-side rendering window does not exist, and some private browsing modes throw on write. Guard access with a feature check.

A safe test is a try/catch that sets and removes a dummy key, returning false if it throws.

Most browsers cap localStorage at roughly five megabytes per origin. Exceeding it throws a QuotaExceededError on write.

This makes localStorage suitable for small data but a poor choice for images, large datasets, or cached API responses.

Good candidates are small, non-sensitive pieces of UI and user state: theme preference, sidebar collapsed state, last-used filters, dismissed banners, and unsaved form drafts.

These are values you want to survive a reload but that do not need a server round trip.

Avoid storing secrets like tokens or passwords, because any script on the page can read localStorage, making it vulnerable to XSS. Also avoid large objects and authoritative server state.

Sensitive auth data belongs in httpOnly cookies, and canonical data belongs on the server.

Both share the same API, but sessionStorage is cleared when the tab closes and is not shared between tabs. localStorage persists indefinitely and is shared across all tabs of the same origin.

Choose sessionStorage for short-lived, tab-specific data and localStorage for lasting preferences.

Cookies are small and sent with every HTTP request, which suits auth but wastes bandwidth for general data. IndexedDB is an asynchronous database for large, structured data well beyond the 5MB limit.

Pick cookies for server-read auth, localStorage for small client prefs, and IndexedDB for big or complex data.

A minimal helper writes with localStorage.setItem(key, JSON.stringify(value)) and reads with a guarded try/catch around JSON.parse(localStorage.getItem(key)), returning a default on failure.

This small wrapper keeps serialization and error handling in one place.

Test your understanding of localStorage data types.

You learned the localStorage API, that it is synchronous, string-only, and capped near 5MB, plus how to parse safely and check availability for SSR and private mode.

You also compared it to sessionStorage, cookies, and IndexedDB to choose the right store.