Cookies vs Local Storage: What's the Difference?
Cookies and local storage are two ways a website saves data in a visitor's browser. Cookies are small pieces of data, up to about 4 KB, that the browser automatically sends to the server with every request, making them ideal for login sessions. Local storage holds larger data, around 5 MB, entirely in the browser and never sends it automatically, making it better for saving preferences or app state. Cookies suit server communication; local storage suits client-side persistence.
- Cookie size
- Roughly 4 KB per cookie, sent to the server on every request (MDN)
- Local storage size
- About 5 MB per origin, never auto-sent to the server (MDN)
- Cookie lifespan
- Set by Expires/Max-Age; session cookies clear on browser close
- Local storage lifespan
- Persists until code or the user clears it, no expiry attribute
- Server access
- Cookies readable server-side; local storage is browser-only
- Privacy law
- Non-essential cookies typically need consent (GDPR/ePrivacy)
What browser storage means #
Every website needs a way to remember things between clicks and visits, because the web is otherwise stateless: each page request starts fresh with no memory of the last. Cookies and local storage are two of the main tools browsers give developers to store small amounts of data on the visitor's own device. Cookies, invented in the 1990s, were the original mechanism and are still essential for logins and sessions. Local storage arrived with HTML5 as part of the Web Storage API to hold larger, purely client-side data more conveniently. They solve overlapping but distinct problems, and choosing the wrong one causes real issues, from bloated requests to broken privacy compliance. If your site handles logins, carts, analytics, or saved preferences, it almost certainly uses one or both. Our /services/web-app-development team selects storage per use case, and our /tools/privacy-policy-generator helps document what your site stores so visitors and regulators can see it clearly and you stay on the right side of consent rules.
How cookies work #
A cookie is a small labeled piece of data, capped at roughly 4 KB, that the server can set through a response header and the browser then stores. Its defining behavior is automatic transmission: the browser attaches matching cookies to every subsequent request to that domain, without any code asking it to. This is exactly why cookies power authentication; once you log in, the server sets a session cookie, and the browser proves your identity on each page you visit by sending it back. Cookies carry attributes that control their behavior: Expires or Max-Age sets how long they live, Domain and Path scope where they apply, and security flags like HttpOnly, Secure, and SameSite protect them from theft and cross-site abuse. The trade-off is that because cookies ride along with every request, storing large or unnecessary data in them wastes bandwidth and slows the site. Cookies are best kept small, focused, and reserved for data the server genuinely needs to see on each request.
How local storage works #
Local storage is a simple key-value store built into the browser, offering roughly 5 MB per site origin, far more than a cookie. Its defining trait is the opposite of a cookie's: data placed in local storage stays in the browser and is never automatically sent to the server. Code reads and writes it on demand using a straightforward JavaScript API, and the data persists indefinitely, surviving browser restarts, until your code deletes it or the user clears their browser. This makes local storage ideal for things the server does not need on every request: interface preferences like a chosen theme, a draft form the user is filling out, cached data to avoid refetching, or the state of a single-page app. Because it is not attached to requests, it adds no per-request overhead. There is also a sibling, sessionStorage, which behaves identically but clears when the tab closes. The main limitations are that local storage is synchronous, string-only, and accessible to any script on the page, so it is unsuitable for secrets.
The two APIs side by side #
The clearest way to see the difference is in code: one line each, doing superficially similar things with very different consequences.
// COOKIE: the browser sends this to the server on every request
document.cookie = "theme=dark; Max-Age=3600; Path=/; Secure; SameSite=Lax";
// LOCAL STORAGE: stays in the browser, never auto-sent
localStorage.setItem("theme", "dark");
const theme = localStorage.getItem("theme"); // "dark"
// sessionStorage: same API, but cleared when the tab closes
sessionStorage.setItem("draft", "unsent message");Size, speed, and lifespan compared #
The practical differences come down to three axes: size, transmission, and lifespan. On size, a cookie holds about 4 KB while local storage holds roughly 5 MB, so anything larger than a short token belongs in local storage. On transmission, cookies are sent to the server automatically with every request, adding overhead that compounds on busy sites, whereas local storage stays local and costs nothing per request. On lifespan, cookies can be set to expire at a precise time or to vanish when the browser closes, giving fine control, while local storage simply persists until explicitly cleared. There is also a shared limitation worth noting: browsers scope both to a single origin, so data saved on one domain is invisible to another. If you find yourself stuffing lots of data into cookies, that is usually a sign the data should live in local storage instead, keeping requests lean, a small change our /services/speed-optimization reviews often flag on template-heavy sites carrying oversized cookies.
Security and privacy considerations #
Security shapes which tool is safe for what. Cookies can carry the HttpOnly flag, which hides them from JavaScript entirely and blocks a common theft technique called cross-site scripting from reading session tokens; local storage has no such protection and is fully readable by any script on the page, so it must never hold passwords, session tokens, or personal secrets. Cookies also support the Secure flag, ensuring they travel only over HTTPS, and SameSite, which limits cross-site sending to curb request forgery. On privacy, cookies used for tracking or analytics are regulated: under GDPR and the ePrivacy Directive, non-essential cookies generally require the visitor's consent before being set, which is why consent banners exist. Local storage used for tracking faces similar scrutiny even though it is not technically a cookie. Whatever you store, disclosing it is part of compliance, and our /services/website-security reviews and /tools/privacy-policy-generator help you handle both the technical hardening and the legal disclosure so your storage choices do not become a liability.
When to use each #
Choose based on who needs the data and how sensitive it is. Use cookies when the server must know something on every request, above all for authentication and sessions, and keep those cookies small and locked down with HttpOnly, Secure, and SameSite. Use local storage for larger, non-sensitive data that only the browser needs, such as remembering a collapsed sidebar, caching a product list to reduce API calls, or preserving an unsent form draft. Use sessionStorage for temporary, tab-scoped state that should disappear when the visitor leaves. A common real-world pattern combines them: an HttpOnly cookie holds the secure session token while local storage caches display preferences and interface state, each doing what it is best at. The guiding questions are simple: does the server need this on every request, and is it sensitive? Yes to both means a hardened cookie; no to both means local storage. Getting this split right keeps requests fast, sessions secure, and personal data out of places scripts can read.
Beyond cookies: IndexedDB and other stores #
Cookies and local storage are the two best-known browser storage tools, but they are not the only ones, and knowing the wider set helps you choose correctly. IndexedDB is a larger, asynchronous database built into browsers, capable of storing hundreds of megabytes of structured data, including files and objects, far beyond local storage's roughly 5 MB and string-only limits. It suits complex web apps that cache large datasets or work offline, such as an email client or a mapping tool. There is also the Cache API, used by service workers to store network responses for offline and fast repeat loading, which underpins progressive web apps. sessionStorage, mentioned earlier, mirrors local storage but clears when the tab closes. The rule of thumb still holds: cookies for small data the server needs, local storage for modest client-only values, and IndexedDB or the Cache API when you outgrow both. Our /services/web-app-development team reaches for IndexedDB when a site needs serious offline capability or large client-side caching beyond what simple key-value storage can comfortably handle.
What this means for your website #
Most business owners never touch this directly, but the choices your developer makes affect your site's speed, security, and legal exposure, so it is worth understanding. A site that dumps everything into cookies sends bloated requests and slows down; a site that stores login tokens in local storage exposes them to theft; a site that sets tracking cookies without consent risks privacy fines. Done well, the pattern is invisible: sessions stay secure, pages stay fast, and your consent banner and privacy policy accurately reflect what is stored. If you are launching a login area, a cart, or any interactive tool, our /services/web-app-development team implements storage the right way from the start, and analytics that rely on cookies are configured for consent through our /services/analytics-tracking work. If you already have a site and are unsure what it stores or whether it complies, a /free-website-audit will inventory its cookies and storage so you know exactly where you stand before a regulator or customer asks.
FAQ
Which is more secure, cookies or local storage?
Cookies can be more secure for sensitive data because they support the HttpOnly flag, which hides them from JavaScript and blocks a common theft method. Local storage is always readable by any script on the page, so it should never hold passwords or session tokens. For secrets, a hardened cookie wins; for harmless preferences, local storage is fine.
Do local storage entries need cookie consent banners?
It depends on purpose, not the technology. If you use local storage purely for essential functions like remembering a language choice, consent is generally not required. If you use it for tracking, advertising, or profiling, privacy laws such as GDPR and ePrivacy typically require consent, just as they do for tracking cookies. Purpose drives the rule.
How much data can each store?
A single cookie holds about 4 KB, and browsers limit how many cookies a site can set. Local storage offers roughly 5 MB per site origin, over a thousand times more. If you need to store more than a small token, local storage is the right choice; cookies should stay small since they travel with every request.
Does local storage get sent to the server?
No. Local storage stays entirely in the browser and is never transmitted automatically. Your code must explicitly read it and send it, for example in a fetch request, if the server needs it. This is the opposite of cookies, which the browser attaches to every request to the matching domain without any code involved.
Can I use local storage instead of cookies for login?
It is risky. Storing a session token in local storage exposes it to any script, making cross-site scripting attacks far more damaging. The safer pattern keeps the session token in an HttpOnly cookie the browser sends automatically, while using local storage only for non-sensitive interface state. Most security guidance recommends cookies for authentication tokens.
What clears cookies and local storage?
Cookies clear at their set expiry, when the browser closes if they are session cookies, or when the user clears browsing data. Local storage has no expiry; it persists until your code deletes it or the user clears their browser storage. Both are also removed if the visitor clears site data manually in browser settings.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?