Local Storage vs Session Storage vs Cookies: What’s Different and What Needs Consent

Browsers give you three main places to keep data on someone’s device, and they behave nothing alike. Cookies travel to your server on every request and cap out around 4 KB. Local storage holds roughly 5 MB, never expires on its own, and never leaves the browser. Session storage works the same way but dies when the tab closes.

The differences matter for performance. They matter more for compliance, and that part catches teams out. UK and EU law doesn’t care which of the three you picked. If you’re storing something on a user’s device, or reading something already there, the same consent rule applies. Most cookie banners were built to manage cookies, so local storage identifiers routinely survive a consent withdrawal that was supposed to remove them.

Cookies and privacy go hand-in-hand, because you’re capturing some level of data. Many countries now have specific cookie law implications that need to be considered to ensure you’re remaining compliant when storing and using browser cookies, however they are stored.From remembering user preferences to enabling offline access, each of the client-side storage mechanisms serves a different purpose and has distinct privacy implications that we outline in this post.

Here’s how the three compare, what actually happens when someone clears their cookies, and which ones you need permission for.

Local storage vs session storage vs cookies at a glance

What is Local Storage? 

Local storage is a type of web storage method that allows website owners to store data on a user’s device in the form of key-value pairs. This web storage method does not expire even upon the user closing the window or tab; the data continues to exist in the browser unless the user clears the browser data cache to erase all local storage data. Local storage has significant advantages over cookies. Unlike most cookies, which are often cleared upon closing the browser, local storage continues to exist on the user device for a lifetime unless the user deletes it manually. While cookies have limited memories (typically up to 4KB) local storage can hold several megabytes, depending on browser limitations. Beyond basic storage, local storage unlocks immense possibilities for websites. It allows websites to access locally stored data even when offline. It enables offline browsing, which is suitable for saving drafts on online writing tools or drawing apps to prevent accidental loss. Local storage undeniably offers benefits for websites and web apps, but data having to be manually deleted or unnoticeably persisting on user devices raises concerns about long-term data retention. It also impacts the user’s ability to make informed choices if they’re not fully aware of what data is locally stored and for what use. Data stored locally can also be used for tracking users even when they are offline. Websites need to have clear privacy policies highlighting how local storage data is collected, used, and shared. Under CCPA, data subjects have the right to opt-out if local storage data is shared with third parties for “sale” or advertising purposes.

What is Session Storage? 

Session storage is very similar to local storage. Session storage is created every time a new document is loaded in a particular tab of a browser. It is typically used for storing temporary data for the current browser session. It differs from local storage in that, while local storage doesn’t expire unless manually deleted, data in session storage is cleared upon closing the page session. Compared to local storage, there are fewer legal implications with session storage. Temporary data holding reduces privacy concerns, and as the data automatically clears upon session closure, security risks also potentially decrease. However, privacy risks like linking with other data to identify individuals remain. For compliance purposes, it is important to determine if session storage data can be combined with other information to potentially identify individuals.

What are the different types of cookies? 

Cookies on behalf of the party by which they are stored in browser directories of users are divided into two types:

• First-party cookies
• Third-party cookies.

When a user interacts with a website, cookies can be created by either the domain being visited itself or domains other than the website. Ultimately, which domain’s server drops the cookies in the user’s browser decides the type of cookies.

Read more about zero party vs. first party vs. third party data.

First-party cookies 

First-party cookies are created by the website itself, which a user interacts with. When a user interacts with a website, its server sends instructions to create a domain-specific cookie file in the user’s browser. The information stored in this cookie contains details regarding user preferences such as language and sign-in details, shopping cart contents, and analytics data. Analytics data could be information about website usage (e.g. page views, average time spent on each page, bounce rate, user movement through the website), user interaction (buttons and links clicked, forms submitted, downloads), and user information (device type, operating system, browser, location, etc.). First-party cookies are retrieved by the domain host upon subsequent visits by the user, allowing website hosts to gather statistical outcomes and boost the browsing experience of the user. These cookies can only track user activity on the original website where the cookies were placed, not other websites. It makes them less privacy-invasive.

Third-party cookies 

Third-party cookies are created by websites other than those with which a user interacts. Often, websites have embedded scripts, like ad trackers, from social media platforms or advertising networks that set their domain-specific cookies on the user’s browser. Third-party cookies contain information about the user’s browser and device, as well as potentially some browsing history data. Website owners mainly place these cookies on their websites to earn ad revenue. Their reliance is also driven by cost-effectiveness, so they don’t need to develop their own versions of features like social media widgets (share buttons, comment sections), live chat support (connecting users with customer service representatives), payment processing (integrating with secure payment gateways), etc. As a user browses through the web, these cookies, wherever they’re embedded, act like beacons and allow the third party to track user activity across different websites. These cookies, thereby, help third parties build a profile of users’ interests and online behavior. This raises serious privacy concerns. Many regulations, like GDPR and CCPA, require websites to obtain user consent for storing and tracking data through third-party cookies. Due to its privacy-invasive nature, major browsers have already started blocking it by default. Google has announced plans to phase them out by the end of 2024.

Other cookie types: 

• Strictly necessary cookies are usually first-party cookies. These cookies do not require user consent. Most cookie laws, including the EU GDPR, exempt necessary cookies from collecting user consent before performing their actions.
• Performance cookies do not collect personally identifiable information (PII), but the data they gather is typically anonymous, like page views, clicks, time spent on each page, etc. Often, performance cookies are perceived as first-party cookies, but they could be third-party cookies too.
• Functional cookies are also referred to as preference cookies. These cookies can be both first-party and third-party. They do not store PII specific to users, but they may indirectly link to a user through device information or browsing behavior.
• Targeting cookies are also known as advertising cookies. Such cookies are mostly third-party cookies. These cookies collect user information about their browsing habits and interests across different websites. These generally lack transparency and collect data extensively; therefore, regulations like GDPR and CCPA require explicit user consent for these to be used.

Does clearing cookies clear local storage?

It depends on what the user actually clears, which is why the answer confuses people.

Local storage survives if only cookies are deleted. It’s removed if the user clears site data, and every major browser bundles the two together in its interface. In Chrome, the option labelled “Cookies and other site data” deletes cookies and local storage, session storage, IndexedDB and Web SQL in one go. Google’s own documentation splits them out: “Cookies” covers the cookie files, while “Site data” covers the HTML5 storage types. Most people tick one box and clear everything, which is why browsers group them.

Narrower deletions behave differently. A cookie-specific browser extension, a document.cookie expiry written by your own JavaScript, or a consent banner’s opt-out will each remove cookies and leave local storage completely intact.

Local Storage vs Session Storage vs Cookies: Choosing the right option for you

Use a cookie when the server needs to read it. Authentication is the clearest case. A session token in an HttpOnly, Secure, SameSite cookie goes out with every request automatically and can’t be read by JavaScript, which limits the damage from cross-site scripting. Put that same token in local storage and any script on your page can read it.

Use local storage for larger client-side data the server doesn’t need. Draft content, cached API responses, UI preferences, offline state. It’s roughly a thousand times the capacity of a cookie, and because it never travels with requests it doesn’t add weight to every single one. Don’t put anything sensitive in it.

Use session storage for state scoped to one tab. Multi-step forms and checkout flows are the obvious fit. A user with two tabs open on your site gets two independent stores, which is usually what you want and occasionally a nasty surprise.

Reach for IndexedDB instead of local storage if you’re storing more than a few kilobytes, need to store anything that isn’t a string, or need a service worker to read it. Local storage is synchronous, so every read and write blocks the main thread. At any real volume it will stall rendering.

Why this matters when someone withdraws consent

This is the part that turns a trivia question into a compliance problem.

When a user rejects analytics in your banner, your CMP deletes the analytics cookies. If your analytics or A/B testing tool also wrote an identifier into local storage, and plenty do, that identifier is still sitting there. The user has withdrawn consent. Your site is still holding the thing they withdrew consent for, and it’ll still be there on their next visit because local storage doesn’t expire.

Two ways to handle it properly. Clear the keys yourself when consent changes:

// Call this when a user withdraws consent for a category.
// Cookie banners delete cookies. Web storage is routinely missed.
const NON_ESSENTIAL_STORAGE_KEYS = ['_analytics_id', 'ab_variant', 'ad_profile'];

function revokeNonEssentialStorage() {
  NON_ESSENTIAL_STORAGE_KEYS.forEach((key) => {
    localStorage.removeItem(key);
    sessionStorage.removeItem(key);
  });
}

Or let the server instruct the browser to clear both at once, using the Clear-Site-Data response header:

Clear-Site-Data: "cookies", "storage"

The header is the cleaner option where it’s supported, because it reaches storage your page-level JavaScript can’t enumerate. Check current browser support before you rely on it as your only mechanism.

How long does each one last?

Session storage lasts as long as the tab. Close it and the data is gone. Opening the same site in a second tab gives you a separate, empty store.

Cookies last as long as you tell them to, via Expires or Max-Age. Set neither and you get a session cookie that’s cleared when the browser closes.

Local storage has no expiry at all. Nothing in the API sets one. Data written today is still there next year unless the user clears it or your code removes it.

With one significant exception. Safari is much more aggressive than Chrome or Firefox, and may evict script-writable storage after around seven days of no interaction with your site. If you’re relying on local storage to remember something across weeks, it’ll work on Chrome and quietly fail for a chunk of your Safari users. Build for that.

If you need a genuine expiry in local storage, you have to write one yourself:

function setWithExpiry(key, value, ttlMs) {
  localStorage.setItem(key, JSON.stringify({ value, expiresAt: Date.now() + ttlMs }));
}

function getWithExpiry(key) {
  const raw = localStorage.getItem(key);
  if (!raw) return null;
  const { value, expiresAt } = JSON.parse(raw);
  if (Date.now() > expiresAt) {
    localStorage.removeItem(key);
    return null;
  }
  return value;
}

That pattern matters for compliance too. Consent records and anything tied to a retention period need an expiry, and local storage won’t give you one for free. Syrenis covers this in more depth in cookie consent expirations.

What needs consent: cookies, local storage and session storage

The law here is simpler than most teams assume, and broader.

Regulation 6 of PECR, the UK implementation of the ePrivacy Directive, applies to storing information on a user’s device or gaining access to information already stored there, by any method. It never said “cookies”. The ICO has now made that unmistakable: its guidance was reissued in April 2026 as guidance on storage and access technologies, deliberately dropping cookies as the framing. Local storage, session storage, IndexedDB, tracking pixels, device fingerprinting and link decoration all sit inside Regulation 6. The EDPB reached the same technology-neutral conclusion on Article 5(3) in its 2023 guidelines.

So the question is never “is this a cookie”. It’s “am I storing or reading something on this person’s device, and does it qualify for an exemption”.

Exemptions. Regulation 6(4) has long provided two: the communication exemption, and the strictly necessary exemption. The strictly necessary test is narrower than the name suggests, because it means necessary from the user’s point of view, not helpful to your commercial interests. Amendments made under the Data (Use and Access) Act have since added further exceptions, including statistical purposes and appearance or function. Those come with conditions: you still have to give users a clear, free and easy way to object, you have to stop storing or accessing immediately when they do, and you can’t treat browser settings as consent.

In practice, for the three technologies on this page:

• A JWT written to local storage after a user logs in is normally strictly necessary. The user asked for the protected area, and the token delivers it. No consent needed.
• A form’s current step in session storage is normally strictly necessary too.
• An analytics or advertising identifier in local storage needs prior consent, exactly as _ga would. The storage mechanism makes no difference.
• Anything linking a user across sites or devices needs consent. No exemption covers it.

The gap in most consent setups

Two failures come up repeatedly, and both are invisible until someone audits the site.

The first is scope. Your cookie banner blocks and clears cookies. It leaves local storage untouched, so a non-essential identifier gets written before consent, or survives its withdrawal. Under a technology-neutral Regulation 6, that’s the same breach it would be with a cookie.

The second is disclosure. Your cookie policy lists cookies. It doesn’t mention the local storage keys your tag manager writes, which means users can’t make an informed choice about storage they don’t know exists.

Both are fixable, and both start with knowing what your site actually writes. Syrenis’s website audit scans for storage and access technologies rather than cookies alone, and cookie management enforces the resulting consent decisions across web storage as well as cookies. We’ve written up what changed in the ICO’s position in ICO updates guidance on storage and access after Data Act changes.

FAQs

Is local storage a cookie?

No. Local storage is part of the Web Storage API, it holds about 5 MB, and it’s never sent to your server. Cookies hold about 4 KB and travel with every matching request. Legally, though, they’re treated identically: PECR Regulation 6 covers both, because it applies to storing information on a device by any method.

Should I use cookies or local storage?

Cookies if the server needs to read the value, which makes them the right choice for authentication. Local storage if the data stays in the browser and is too big for a cookie. An HttpOnly cookie can’t be read by JavaScript, so it’s the safer place for a session token.

Why use cookies instead of local storage?

Three reasons. Cookies reach your server automatically, so server-rendered pages can act on them. HttpOnly cookies are shielded from cross-site scripting, which local storage isn’t. And cookies support real expiry dates, while local storage has no expiry mechanism at all.

Is it better to have cookies on or off?

Blocking all cookies breaks logins, shopping carts and saved preferences on most sites. Blocking third-party cookies is the useful middle ground, and Safari and Firefox have done it by default since 2020. That limits cross-site tracking while leaving normal site functionality alone.

Does local storage need consent under GDPR?

It depends on the purpose, and the relevant law is usually ePrivacy or PECR rather than GDPR itself. Storing a login token you need to deliver a service is strictly necessary and exempt. Storing an analytics or advertising identifier needs prior consent, exactly as an equivalent cookie would.

What is DOM storage?

DOM storage is the older name for the Web Storage API, covering both localStorage and sessionStorage. You’ll still see it in documentation and browser settings. It means the same thing as web storage.