</> ConvertAtlas Developer Tools
Web

Cookies vs localStorage vs sessionStorage

Three ways to store data in the browser, what sets them apart, and which to use for tokens, preferences and more.

ConvertAtlas 7 min read Updated June 2026
Browser Server Set-Cookie Cookie: sent back each request

The browser gives you several places to stash data, and they are not interchangeable. Picking the wrong one leads to data that vanishes unexpectedly, bloated requests, or security holes. Here is how cookies, localStorage and sessionStorage actually differ.

Browser Server Set-Cookie Cookie: sent back each request
Cookies travel to the server on every request; localStorage and sessionStorage stay in the browser.

Cookies

Cookies are small pieces of data the browser sends to the server with every matching request. That automatic transmission is their defining trait — it is how servers recognize sessions — but it also means cookies add weight to every request, so they should stay small. Cookies can be configured with flags that make them genuinely secure: HttpOnly hides them from JavaScript, Secure restricts them to HTTPS, and SameSite limits cross-site sending.

localStorage

localStorage stores key-value strings in the browser with no expiry — data persists until explicitly cleared, even across browser restarts. It is never sent to the server, holds far more than a cookie (megabytes), and is read and written purely by JavaScript. It suits client-side preferences and cached data, but because any script on the page can read it, it is a poor place for sensitive tokens.

sessionStorage

sessionStorage works just like localStorage but with a shorter life: data lasts only for the current tab and is cleared when the tab closes. It is ideal for transient state that should not outlive the session — a multi-step form’s progress, or a scroll position — and that should not leak between tabs.

Where to store auth tokensThe token-storage debate: localStorage is vulnerable to XSS (any injected script can read it), while an HttpOnly cookie is hidden from JavaScript but vulnerable to CSRF unless protected with SameSite. There is no perfect spot — defend against both threats.

Choosing

  • Need the server to read it automatically (sessions)? Cookie, with HttpOnly, Secure and SameSite.
  • Client-only data that should persist? localStorage.
  • Client-only data for this tab only? sessionStorage.
  • Anything sensitive? Think hard about XSS and CSRF regardless of choice.
Try it: URL ParserParse a URL into its protocol, host, path, query parameters and more.
Key takeaways
  • Cookies go to the server every request; web storage stays in the browser.
  • localStorage persists indefinitely; sessionStorage clears with the tab.
  • Secure cookies use HttpOnly, Secure and SameSite flags.
  • No storage is immune — defend against both XSS and CSRF.

Frequently asked questions

Is localStorage safe for JWTs?

It is convenient but exposed to XSS — any injected script can read it. Many teams prefer HttpOnly cookies with SameSite protection, accepting the CSRF trade-off.

How much can localStorage hold?

Typically around 5–10 MB per origin, far more than a cookie’s roughly 4 KB.