# Cookies vs Local Storage

URL: https://softwaredictionary.org/compare/cookie-vs-local-storage
Last updated: 2026-09-30

In short: Cookies are small data the browser sends to the server with every matching request, while local storage keeps larger data in the browser and never sends it.

## What is the difference between cookies and local storage?

A cookie is a small name-value pair that a server sets with the `Set-Cookie` header, or that a script sets, and that the browser attaches to later requests to the same site. Local storage is a browser API, `localStorage`, that lets JavaScript save strings under keys for one origin, with no automatic network traffic.

The core difference is who the data is for. Cookies exist so the server can recognize the browser, which is why they travel with every request and are limited to about 4 KB each. Local storage exists for the page's own scripts, so it holds more, typically around 5 MB per origin, and adds nothing to requests.

They often work side by side. A site may keep the login session in an `HttpOnly` cookie, which JavaScript cannot read, and store interface preferences such as a theme or an unsent draft in local storage. Both are scoped: cookies to a domain and path, local storage to an exact origin (scheme, host and port).

A common misconception is that local storage is a safe place for authentication tokens. Any script running on the page, including one injected through an XSS flaw, can read it, while an `HttpOnly` cookie is out of JavaScript's reach. Local storage also never expires on its own; it stays until code or the user clears it.

| Aspect | Cookie | Local Storage |
| --- | --- | --- |
| Sent to the server | Automatically, with every matching HTTP request | Never; scripts must send the data explicitly |
| Size limit | About 4 KB per cookie | About 5 MB per origin in most browsers |
| Expiration | Set with `Expires` or `Max-Age`, or ends with the browser session | None; persists until cleared by code or the user |
| JavaScript access | Readable via `document.cookie` unless marked `HttpOnly` | Always readable by any script on the same origin |
| Scope | A domain and path, optionally including subdomains | One exact origin: scheme, host and port |
| API | The `Set-Cookie` header and the `document.cookie` string | Simple `setItem`, `getItem` and `removeItem` methods |
| Best for | Sessions, authentication and settings the server needs | Client-only settings, caches and unsaved drafts |

## Choose Cookie when

- The server needs the value on every request, like a session ID.
- You want to keep JavaScript away from it with the `HttpOnly` flag.
- The data should expire automatically at a set time.

## Choose Local Storage when

- Only client-side code needs the data.
- You need more space than a few kilobytes.
- The data should not add weight to every request.

## Frequently asked questions

**Is local storage more secure than cookies?**

Not for secrets. Any script on the page can read local storage, so an XSS bug can steal what is stored there; an `HttpOnly`, `Secure` cookie is the safer place for session tokens.

**Does clearing cookies also clear local storage?**

Usually, yes. In most browsers, the option to clear cookies and site data removes local storage too, although some settings let you clear them separately.

**What is the difference between local storage and session storage?**

They share the same API, but `sessionStorage` is scoped to a single browser tab and is cleared when that tab closes, while `localStorage` persists across tabs and restarts.

---

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