Skip to main content
Cookie Gate
Category: Tracking Technologies

Web Storage API

Also known as: Web Storage, HTML Web Storage
Simply put

The Web Storage API is a feature built into web browsers that lets websites and applications store data directly on the user's device, within the browser itself. It works by saving information as simple name-and-value pairs, and it serves as an alternative to storing data in cookies. Although it is not a cookie, it can be used to hold information about a user on their device, which is why it is relevant to consent and privacy discussions.

Formal definition

The Web Storage API is a browser-provided set of interfaces that allow client-side scripts to securely store key/value string pairs on the user's device. As defined in the WHATWG HTML specification, it introduces two related mechanisms for storing name-value pairs client-side, described as similar to HTTP session cookies. From a compliance perspective, although Web Storage is technically distinct from cookies, the act of storing or accessing information on a user's device via these mechanisms generally falls within the same rules that govern cookies under the EU ePrivacy Directive (and its national implementations), which regulate the storing of and access to information on terminal equipment regardless of the specific technology used. Where the stored data constitutes personal data, its subsequent processing is separately subject to the GDPR. The evidence provided describes the technical function of the API only and does not address specific consent-classification outcomes, which depend on the purpose of the storage and applicable jurisdictional guidance; whether a given use requires prior consent is a fact-specific and evolving question that should be assessed case by case.

Why it matters

The Web Storage API matters to privacy and compliance teams because it is frequently discussed as an alternative to cookies, yet the fact that it lives outside the traditional cookie mechanism does not place it outside the scope of consent obligations. In most EU jurisdictions, the ePrivacy Directive (and its national implementations) regulates the storing of and access to information on a user's terminal equipment regardless of the specific technology used, so storing name-value pairs in Web Storage generally falls within the same rules that govern cookies rather than escaping them. Teams that assume 'not a cookie' means 'not regulated' may misclassify these mechanisms in their consent inventories.

Who it's relevant to

Web Developers and Engineering Teams
Developers implementing Web Storage should recognize that choosing it over cookies does not, by itself, remove the storage from the scope of consent rules. Because these mechanisms store information on the user's device, engineering teams generally need to coordinate with privacy stakeholders to ensure that any non-essential use is gated appropriately and reflected accurately in the site's technology inventory.
Privacy Officers and Data Protection Professionals
Privacy teams maintaining cookie and tracking inventories should account for Web Storage alongside cookies, pixels, and similar client-side technologies. In most EU jurisdictions the ePrivacy Directive regulates access to terminal equipment regardless of the specific technology, so relying on the label 'not a cookie' risks under-scoping consent obligations. Whether a given use requires prior consent is fact-specific and should be assessed against current guidance.
Legal Counsel and Compliance Teams
Counsel advising on consent classification should note that the technical distinction between Web Storage and cookies does not determine the compliance outcome. The purpose of the storage, whether the stored data is personal data subject to the GDPR, and the applicable jurisdictional guidance all bear on whether consent is required, and these questions can differ between the EU, the UK, and individual US states.

Inside Web Storage API

localStorage
A key-value storage mechanism that persists data in the browser without an expiration time, remaining available across browser sessions until explicitly cleared. It is accessible only to pages sharing the same origin.
sessionStorage
A key-value storage mechanism scoped to a single browser tab or session, where stored data is cleared when the tab or window is closed. Like localStorage, it is bound to the same origin.
Client-side storage of information on a device
Both mechanisms store and retrieve information on the user's terminal equipment. In most EU jurisdictions, placing or accessing such information falls within the scope of the ePrivacy Directive's rules on storing and accessing information on a device, in the same way as cookies, even though these are not literally cookies.
Same-origin restriction
Access to Web Storage is limited to scripts running on the same origin (scheme, host, and port) that stored the data, which affects who can read and write the stored values.

Common questions

Answers to the questions practitioners most commonly ask about Web Storage API.

Is the Web Storage API exempt from consent because it is not technically a cookie?
No. Although localStorage and sessionStorage are not cookies, they involve storing and accessing information on a user's device, which in most EU jurisdictions falls within the scope of the ePrivacy Directive's rules on that same activity. As a result, the consent analysis generally turns on the purpose of the storage rather than the specific technology used. Web Storage used for non-essential purposes such as analytics or advertising typically requires the same prior consent that would be needed for equivalent cookies, while storage that is strictly necessary to provide a service the user has requested may fall within the exemption on the same basis as essential cookies.
Does using the Web Storage API let a site avoid GDPR obligations that apply to cookies?
Not in itself. The ePrivacy rules on storing or accessing information on a device apply regardless of the mechanism, and separately the GDPR applies whenever the values stored constitute or relate to personal data. If Web Storage holds identifiers or other personal data, the processing that follows is generally subject to the GDPR's requirements, including a lawful basis and transparency. Switching from cookies to Web Storage changes the technical implementation but does not by itself remove either the ePrivacy consent question or the GDPR processing obligations.
How should Web Storage entries be categorized within a consent management platform?
Entries are generally categorized by their purpose rather than their storage mechanism, so that a CMP can treat localStorage or sessionStorage items in the same categories it uses for cookies, such as strictly necessary, functional, analytics, or advertising. Because CMPs often focus on cookies, teams may need to inventory Web Storage usage manually and map each item to the correct category. A CMP can support this categorization, but it does not replace the legal judgment needed to decide which items are genuinely essential and which require consent.
How can non-essential Web Storage writes be deferred until consent is obtained?
As a practical matter, code that writes non-essential values to localStorage or sessionStorage can be gated so it only executes after the relevant consent signal is recorded, in the same way that non-essential cookie-setting scripts are blocked until consent. This typically requires identifying every place in the codebase and in third-party SDKs where Web Storage is written for analytics, advertising, or similar purposes, and wiring those writes to the consent state. The appropriate approach depends on the site's architecture and the jurisdictions it serves, so the technical gating should reflect the consent standard applicable to those users.
What happens to existing Web Storage data when a user withdraws or declines consent?
Where consent is declined or later withdrawn, non-essential Web Storage items associated with that purpose should generally be prevented from being written and, where already present, cleared, so that the storage state reflects the user's choice. Because localStorage persists until explicitly removed and sessionStorage clears when the tab session ends, teams typically need to script the removal of relevant keys rather than relying on expiry. The specifics of what must be cleared depend on which items are treated as non-essential and on the applicable legal scope, which the definition does not resolve for any particular site.
How should Web Storage usage be reflected in a cookie or privacy notice?
Because transparency obligations generally attach to the purpose of storing and accessing information rather than to the label 'cookie,' notices that describe tracking technologies commonly extend to Web Storage and similar mechanisms. In practice this means disclosing that localStorage or sessionStorage is used, for what purposes, and by whom, alongside cookies and comparable technologies. The level of detail expected can vary by jurisdiction and by regulator guidance, so the wording should be reviewed against the standards applicable to the site's users rather than assumed to be uniform.

Common misconceptions

Web Storage is not covered by cookie consent rules because it does not use cookies.
Because localStorage and sessionStorage involve storing and accessing information on a user's device, they generally fall within the same ePrivacy rules that govern cookies in most EU jurisdictions. The technology used is not what determines the obligation; the act of storing or accessing information on the device is. Where any resulting processing involves personal data, the GDPR may also apply separately.
sessionStorage requires no consent because it is temporary and cleared when the tab closes.
The temporary nature of sessionStorage does not by itself exempt it from consent requirements. Whether consent is needed typically depends on the purpose of the storage rather than its duration; storage that is strictly necessary for a service the user requested may be exempt, while analytics or advertising purposes generally require prior consent under EU law regardless of how long the data persists.
Using Web Storage instead of cookies is a way to avoid consent obligations.
Substituting Web Storage for cookies does not remove consent obligations. Non-essential uses of localStorage or sessionStorage are generally treated comparably to non-essential cookies under EU rules, so switching technologies does not change the underlying compliance analysis.

Best practices

Assess each use of localStorage and sessionStorage by purpose, distinguishing strictly necessary storage that may be exempt from analytics, advertising, or other non-essential purposes that typically require prior consent under EU law.
Inventory Web Storage usage alongside cookies, pixels, SDKs, and similar technologies so that your consent management approach covers all methods of storing or accessing information on a device, not only literal cookies.
Where consent is required, obtain it through a clear affirmative action before writing non-essential data to Web Storage, and avoid relying on pre-ticked boxes, implied consent, or cookie walls, which are widely considered non-compliant in the EU.
Configure your consent management platform (CMP) to gate non-essential Web Storage writes on the appropriate consent signal, recognizing that a CMP supports compliance but does not replace legal judgment.
Confirm the geographic and legal scope of your obligations, as requirements differ between the EU, the UK, and individual US states such as California under the CCPA and CPRA, which often rely on opt-out rather than opt-in.
Maintain records of consent and of how Web Storage is used and cleared, and document any determination that a given use is strictly necessary, so decisions can be justified if enforcement positions or guidance evolve.