# localStorage vs sessionStorage

URL: https://softwaredictionary.org/compare/local-storage-vs-session-storage
Last updated: 2026-10-06

In short: Both store strings by key with the same API; localStorage keeps data for every tab until deleted, while sessionStorage keeps it for one tab until it closes.

## What is the difference between localStorage and sessionStorage?

`localStorage` and `sessionStorage` are the two halves of the Web Storage API built into every browser. Both store strings under string keys for one origin, both offer the same methods, `setItem`, `getItem`, `removeItem` and `clear`, and both are synchronous and typically limited to about 5 MB per origin. In either one, objects are saved with `JSON.stringify` and read back with `JSON.parse`.

The essential difference is lifetime and scope. `localStorage` data is shared by every tab and window of the same origin and stays until code or the user deletes it, even after the browser restarts. `sessionStorage` data belongs to one origin in one tab: it survives reloads and back-and-forth navigation, but a new tab starts empty, even for the same site, and closing the tab deletes it.

So the choice follows from how long the data should live. A theme, a language or a dismissed banner should be remembered on every visit, so it belongs in `localStorage`; a half-filled multi-step form, a scroll position or a notice shown once per tab belongs to the current tab, so it goes in `sessionStorage`. Many apps use both. Changes to `localStorage` also fire a `storage` event in the site's other open tabs, which lets them stay in sync.

A common misconception is that `sessionStorage` is tied to a login session or a session cookie. It has nothing to do with the server: it is never sent with requests, and unlike a session cookie, which every tab shares until the browser closes, it belongs to one tab. Neither store is safe for passwords or tokens, since any script on the page, including one injected through XSS, can read both.

| Aspect | Local Storage | Session Storage |
| --- | --- | --- |
| Lifetime | Until code or the user deletes it | Until its tab is closed; survives reloads |
| Scope | Shared by every tab and window of the same origin | One tab only; each new tab starts empty, even for the same site |
| After a browser restart | Still there | Gone, unless the browser restores the tab |
| API | `setItem`, `getItem`, `removeItem` and `clear` | The same methods, on `sessionStorage` |
| Size limit | About 5 MB per origin in most browsers | The same, about 5 MB per origin |
| Cross-tab sync | Other tabs learn of changes through the `storage` event | Not possible; each tab's data stays private to it |
| Typical use | Theme, language, dismissed banners, saved settings | Multi-step form drafts, scroll position, once-per-tab notices |

## Choose Local Storage when

- The data should still be there on the next visit, such as a theme or language.
- Every tab of the site should see the same value.
- Tabs need to react to each other's changes through the `storage` event.

## Choose Session Storage when

- The data matters only during the current visit, such as a half-filled form.
- Each tab should keep its own state, for example two different searches side by side.
- Nothing should linger in the browser once the tab is closed.

## Frequently asked questions

**Does sessionStorage survive a page refresh?**

Yes. Reloading the page, or navigating away and back in the same tab, keeps the data. Closing the tab clears it.

**Is sessionStorage cleared when the browser closes?**

Yes, along with every tab, although a browser that restores your previous tabs on startup may restore their session storage too. `localStorage` stays either way.

**Which one is safer for storing tokens?**

Neither. Any script on the page can read both, so an XSS flaw exposes them; `sessionStorage` only shortens how long a stolen value stays around. Session tokens are safer in `HttpOnly` cookies.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt