Skip to main content
Cookie Gate
Category: Tracking Technologies

Local Storage

Also known as: localStorage, Web Storage (localStorage)
Simply put

Local Storage is a feature built into web browsers that lets a website save small pieces of information directly on your device, such as your settings or consent choices. Unlike some cookies, this data has no expiration date and remains available even after you close and reopen the browser. Because it stores information on a user's device, it can raise the same consent considerations that apply to cookies, depending on what is stored and where the user is located.

Formal definition

Local Storage is part of the HTML Web Storage API (the localStorage object), which allows a website's scripts to persist key-value string pairs in the browser with no built-in expiration. The data is domain-scoped, persists across browser sessions until explicitly cleared, and is accessible to client-side code on the originating site. Although it is not a cookie, Local Storage involves both storing and accessing information on a user's terminal equipment, which in most EU jurisdictions falls within the scope of the ePrivacy rules governing device storage and access; where non-essential purposes such as analytics or advertising are involved, prior consent is generally required. Any personal data subsequently processed via Local Storage is additionally governed by the GDPR in the EU. Requirements differ under other regimes, such as US state privacy laws that often rely on opt-out mechanisms, and the precise obligations depend on the nature and purpose of the stored data. This definition addresses the technology in general terms and does not resolve jurisdiction-specific classification of any particular Local Storage use.

Why it matters

Local Storage matters for compliance because it is frequently overlooked in cookie audits. Many organisations focus their consent efforts on cookies specifically, while Local Storage, along with related technologies such as pixels and SDKs, can store and access information on a user's device in ways that raise the same regulatory considerations. Because Local Storage involves both storing and accessing information on a user's terminal equipment, in most EU jurisdictions it generally falls within the scope of the ePrivacy rules that govern device storage and access, regardless of the fact that it is technically distinct from a cookie.

The persistence of Local Storage adds to its significance. Unlike cookies that may carry an expiration date, data written to Local Storage has no built-in expiration and remains on the device across browser sessions until it is explicitly cleared. This durability makes it attractive for legitimate purposes such as remembering settings or storing a user's consent choices, but it can also be used for analytics or advertising purposes that typically require prior consent in the EU. Where Local Storage is used for non-essential purposes, the same consent standards that apply to non-essential cookies generally apply here as well.

Because requirements differ across jurisdictions, teams should not assume that a single approach satisfies every regime. EU and UK expectations around prior consent for non-essential storage differ from several US state privacy laws, which often rely on opt-out mechanisms rather than opt-in. The precise obligations depend on the nature and purpose of what is stored, and the classification of any particular Local Storage use may be contested or unresolved, so this concept should be assessed against the specific facts and applicable law rather than treated as automatically exempt.

Who it's relevant to

Privacy officers and data protection professionals
Those responsible for cookie audits and consent governance need to account for Local Storage alongside cookies, because it can involve storing and accessing information on a user's device and may trigger consent obligations for non-essential purposes in most EU jurisdictions. Treating it as out of scope simply because it is not literally a cookie can leave gaps in a compliance programme.
Web developers and engineers
Developers implementing the localStorage API should be aware that the data they persist has no built-in expiration and remains until explicitly cleared. Coordinating with privacy teams on what is stored, its purpose, and whether it should be gated behind prior consent helps ensure that technical implementation aligns with the applicable legal requirements.
Legal counsel and compliance advisers
Counsel assessing tracking technologies should consider that Local Storage may fall within both the ePrivacy rules on device storage and access and, where personal data is processed, the GDPR in the EU, while obligations differ under US state privacy laws and other regimes. Because the classification of a particular use can be contested and depends on its purpose, a fact-specific analysis is generally warranted.
Marketing and analytics compliance teams
Teams deploying analytics or advertising functionality that relies on Local Storage should recognise that these non-essential purposes typically require prior consent in the EU and UK, and that consent management tools support but do not by themselves guarantee compliance. Verifying that such storage is only used after appropriate consent, where required, helps reduce exposure.

Inside Local Storage

Client-side key-value storage
Local storage is a web browser feature that allows websites to store data as key-value pairs directly on the user's device, persisting across browser sessions until explicitly cleared.
Part of the Web Storage API
It sits alongside sessionStorage within the Web Storage API. Local storage retains data indefinitely, whereas sessionStorage is cleared when the browsing session ends.
Distinct from cookies technically
Unlike cookies, local storage data is not automatically transmitted to the server with each HTTP request. It is accessed via JavaScript on the client side, though data may subsequently be sent to a server through other means.
Storage of and access to information on a user's device
Because local storage involves both placing information on and reading information from a user's terminal equipment, it generally falls within the scope of the ePrivacy Directive in the EU, which is not limited to cookies but covers similar technologies.
Potential processing of personal data
Where the information stored in or derived from local storage constitutes personal data, its subsequent processing is generally also subject to the GDPR in the EU, separately from the ePrivacy rules on device access.

Common questions

Answers to the questions practitioners most commonly ask about Local Storage.

Is local storage exempt from consent requirements because it isn't technically a cookie?
No. In most EU jurisdictions, the ePrivacy Directive's rules on storing or accessing information on a user's device are technology-neutral and generally apply to local storage in the same way they apply to cookies. The fact that local storage is not literally a cookie does not, by itself, remove it from scope. Where local storage is used for non-essential purposes such as analytics or advertising, prior consent is typically required, whereas use that is strictly necessary to provide a service the user has requested may be exempt. The relevant question is generally the purpose of the storage and access, not the specific technical mechanism.
Does obtaining cookie consent automatically cover our use of local storage?
Not necessarily, and it should not be assumed. Consent must be specific and informed, so if your consent notice and mechanism address only cookies and do not disclose or account for local storage, the consent obtained may not validly cover local storage use. Where local storage is deployed for the same purposes as consented cookies and is disclosed accordingly, it may fall within the same consent, but this depends on how the notice, purposes, and consent choices are framed. Separately, remember that consent for placing or accessing information on the device (under ePrivacy rules) and any lawful basis for processing personal data that follows (under the GDPR) are distinct considerations.
How can we identify what our site stores in local storage?
Local storage can typically be inspected through browser developer tools, which show the keys and values stored under a given origin. Automated cookie and tracker scanning tools may also detect local storage usage, though coverage varies and scans do not always capture storage triggered only after certain user interactions or by third-party scripts. Because third-party SDKs and tags may write to local storage dynamically, a combination of manual inspection and repeated scanning across different user journeys generally gives a more complete picture. Any inventory should record the purpose of each stored item to support decisions about whether it is essential or requires consent.
Should local storage items be blocked before consent is obtained?
For non-essential purposes, the general expectation in most EU jurisdictions is that information should not be stored on or read from the device before valid consent is given, which typically means writing to and reading from local storage for those purposes should be suppressed until consent is recorded. This often requires configuring or gating the scripts that create local storage entries, since a consent management platform may not automatically control local storage the way it might handle certain cookies. Strictly necessary local storage used to deliver a service the user has requested may generally operate without prior consent. Implementation details depend on how your scripts and tag management are set up, and technical controls should be validated rather than assumed to work.
How should we handle deletion of local storage when a user withdraws or declines consent?
Because withdrawal of consent should be as easy as giving it, and continued storage for non-essential purposes generally requires a valid legal basis, it is common practice to clear local storage entries associated with declined or withdrawn purposes. Local storage does not expire automatically the way cookies with an expiry can, so entries may persist on the device until explicitly removed by script, by the site, or by the user. Cleanup logic typically needs to be implemented deliberately, targeting the specific keys tied to the relevant purposes. The appropriate approach depends on which items are essential, how they are keyed, and your record-keeping around consent changes.
What should we document about local storage for consent record-keeping?
It is generally advisable to include local storage in your broader inventory of storage and tracking technologies, recording each item's purpose, the party responsible (first or third party), whether it is treated as essential or consent-dependent, and how it is controlled relative to the user's consent choices. Where consent is relied upon, maintaining records of consent that reflect the purposes for which local storage is used can support demonstrating compliance. The specific record-keeping expectations vary by jurisdiction and by the frameworks you rely on, and documentation supports but does not by itself establish that a given use is lawful.

Common misconceptions

Local storage is not a cookie, so cookie consent rules do not apply.
In most EU jurisdictions, the ePrivacy Directive governs the storing of and access to information on a user's device regardless of the specific technology used. Local storage, pixels, SDKs, and fingerprinting can fall within the same consent rules as cookies even though they are not literally cookies. Whether consent is required generally depends on the purpose and whether the storage is strictly necessary.
Because local storage stays on the user's device and is not sent with each request, no consent is ever needed.
The relevant question is typically the purpose of the storage and access, not whether data is transmitted automatically. Storage used for analytics, advertising, or other non-essential functions may require prior consent in the EU, while storage that is strictly necessary to provide a service the user requested may be exempt. This assessment is fact-specific and can vary by jurisdiction.
A consent management platform will automatically handle local storage the same way it handles cookies.
CMPs can support governance of local storage, but coverage is not automatic. Because local storage is set via JavaScript and behaves differently from cookies, it may require specific configuration and testing. Tools support compliance but do not replace legal judgment or guarantee that all storage technologies are correctly gated behind consent.

Best practices

Inventory all local storage usage on your site or app alongside cookies and other similar technologies such as pixels, SDKs, and fingerprinting, and document the purpose of each item.
Assess each local storage item's purpose to determine whether it is strictly necessary or whether prior consent may be required in the EU, and apply the relevant standard for your target jurisdictions rather than assuming one regime applies universally.
Where consent is required in the EU, ensure non-essential local storage is not written or read before valid consent is obtained through a clear affirmative action, avoiding reliance on pre-ticked boxes, implied consent, or cookie walls.
Test that your consent management platform actually blocks and releases local storage in line with user choices, since coverage may require specific configuration and does not happen automatically.
Maintain records of consent and of the purposes and scope of local storage to support accountability and any record-keeping obligations, recognizing that requirements differ across the EU, UK, and US state frameworks.
Seek legal advice for contested or fact-specific cases, as the classification of a given local storage item and applicable obligations can depend on facts and evolving regulatory guidance not resolved by a general definition.