Skip to main content
Cookie Gate
Category: Tracking Technologies

IndexedDB

Also known as: Indexed Database API, Indexed Database API 3.0
Simply put

IndexedDB is a database built into web browsers that lets websites and web applications store significant amounts of structured data directly on a user's device. Because it can retain data such as records, objects, and files locally, it is one of the storage mechanisms that may fall within the same consent rules that apply to cookies. Whether its use requires consent generally depends on the purpose of the data stored and the applicable legal regime.

Formal definition

IndexedDB is a low-level, client-side, transactional NoSQL storage API defined by the W3C's Indexed Database API specification. It stores records consisting of keys and hierarchical values (including simple values, structured objects, and files/blobs), and supports indexes for high-performance searching and retrieval of large volumes of data within the browser. From a compliance perspective, IndexedDB is not a cookie but is a form of storing information on, and accessing information from, a user's terminal device; in most EU jurisdictions the ePrivacy Directive's rules on device storage and access apply to such technologies regardless of whether they are literally cookies, and any subsequent processing of personal data would separately engage the GDPR. Consent obligations therefore typically turn on whether the stored data is strictly necessary for a service the user requested (potentially exempt) versus used for analytics, advertising, or other non-essential purposes (generally requiring prior consent under EU law), while opt-out approaches may apply under certain US state privacy frameworks. This definition does not resolve fact-specific questions about a particular deployment, and the classification of any given IndexedDB use depends on its actual purpose and configuration.

Why it matters

IndexedDB matters to compliance teams because cookie consent obligations are not limited to cookies in the strict technical sense. In most EU jurisdictions, the ePrivacy Directive's rules on storing information on, or accessing information from, a user's device apply to a range of client-side technologies, and IndexedDB is a form of storing and retrieving data on the user's terminal. As a result, deploying IndexedDB can trigger the same prior-consent analysis that applies to non-essential cookies, depending on the purpose of the data being stored.

Because IndexedDB can hold significant amounts of structured data, records, objects, and files or blobs, directly in the browser, it can be used for a wide spectrum of purposes, from caching content needed to deliver a service the user requested to storing identifiers or profiles used for analytics or advertising. Where the data serves purposes that are strictly necessary for a user-requested service, its use may be exempt from consent under EU rules; where it supports analytics, advertising, or similar non-essential purposes, prior consent is generally required in the EU. The distinction turns on the actual purpose and configuration of each deployment rather than on the technology itself.

A further consideration is that the ePrivacy analysis (governing device storage and access) and the GDPR analysis (governing any subsequent processing of personal data) are separate. Consent or an exemption under one regime does not automatically satisfy the other. Requirements also differ outside the EU: the UK applies its own implementation, and certain US state privacy frameworks may rely on opt-out rather than opt-in approaches. Teams should therefore assess IndexedDB usage against the specific legal regime that applies to their users.

Who it's relevant to

Web developers and engineering teams
Developers who implement IndexedDB for client-side storage should be aware that its use may fall within device storage and access rules even though it is not a cookie. Documenting what data is stored, for what purpose, and whether it is strictly necessary for a user-requested service helps compliance colleagues determine whether prior consent is required in the EU or whether an exemption may apply.
Privacy officers and data protection professionals
Privacy teams need to account for IndexedDB when auditing tracking and storage technologies, since consent obligations in the EU are not confined to cookies. They should assess each deployment against both the ePrivacy device storage and access rules and, where personal data is processed, the GDPR, recognizing that these are separate analyses and that requirements differ across the EU, the UK, and US state frameworks.
Legal counsel and compliance advisers
Counsel advising on cookie and tracking compliance should evaluate IndexedDB use on a fact-specific basis, focusing on the actual purpose and configuration of the stored data. Because classification as strictly necessary versus non-essential depends on those facts, and because enforcement positions and guidance evolve, definitive conclusions generally require examining the specific deployment rather than the technology in the abstract.
Marketing and analytics compliance teams
Teams deploying analytics or advertising functionality should note that using IndexedDB for such non-essential purposes generally requires prior consent under EU law, while certain US state privacy frameworks may rely on opt-out approaches. Coordinating with consent management processes helps ensure that data stored via IndexedDB is handled consistently with the applicable legal regime.

Inside IndexedDB

Client-side database storage
IndexedDB is a browser-based, low-level API for storing significant amounts of structured data on a user's device, including files and objects, using key-value stores and indexes. It is a client-side storage mechanism rather than a cookie.
Persistent storage on the user's device
Data written to IndexedDB persists on the device across sessions until it is cleared, meaning it can be used to store or retrieve information from a user's terminal equipment in a manner comparable to cookies for regulatory purposes.
Scope within the ePrivacy framework
Because placing or accessing information on a user's device generally falls within the ePrivacy Directive and its national implementations in the EU, using IndexedDB to store or read information typically engages the same consent considerations as cookies, even though it is not literally a cookie.
Relationship to the GDPR
Where information stored or retrieved via IndexedDB constitutes or leads to the processing of personal data, the GDPR applies to that processing in addition to any ePrivacy consent obligation for the storage or access itself. The two regimes address distinct questions and are not automatically satisfied by one another.
Potential use for tracking
IndexedDB can be used to persist identifiers or profiling-related data, placing it among the non-cookie technologies (such as local storage, pixels, SDKs, and fingerprinting) that fall within the same rules as cookies when used for non-essential purposes.

Common questions

Answers to the questions practitioners most commonly ask about IndexedDB.

Is IndexedDB exempt from consent because it isn't technically a cookie?
No. Although IndexedDB is not literally a cookie, the ePrivacy rules in most EU jurisdictions apply to any storing of or gaining access to information on a user's device, regardless of the technology used. Writing to or reading from IndexedDB therefore generally falls within the same consent framework as cookies. Whether prior consent is required depends on the purpose: storage that is strictly necessary to provide a service explicitly requested by the user may be exempt, while use for analytics, advertising, or similar purposes typically requires prior consent in the EU. The technical form of the storage does not change this analysis.
Does obtaining cookie consent automatically cover data I store in IndexedDB?
Not necessarily. Consent must generally be specific and informed, which means it should reflect the actual purposes for which information is stored or accessed. If your consent notice and mechanism describe only cookies but you also use IndexedDB for the same or additional purposes, the consent may not validly cover that activity. Separately, the ePrivacy rules govern the placing of and access to information on the device, while the GDPR governs any subsequent processing of personal data; satisfying one does not automatically satisfy the other. You should ensure your disclosures and consent capture accurately reflect the storage technologies and purposes involved.
How can I prevent IndexedDB writes until a user has given consent?
Where prior consent is required in the EU, the general approach is to gate any non-essential IndexedDB operations behind the consent signal, so that scripts do not open or write to relevant object stores until the user has taken a clear affirmative action. This may involve deferring the initialization of libraries or SDKs that rely on IndexedDB until consent is recorded. The specific implementation depends on your architecture and on which storage counts as strictly necessary, which is a fact-specific and sometimes contested assessment. Legal judgment about categorization should accompany the technical controls.
How should IndexedDB storage be reflected in a cookie or storage audit?
A thorough audit generally documents all client-side storage mechanisms, not only cookies, so IndexedDB databases and object stores should be inventoried alongside pixels, local storage, SDKs, and similar technologies. For each entry it is common to record the purpose, the party responsible, the categorization (for example strictly necessary versus analytics or advertising), and the data retained. Because IndexedDB is less visible than cookies in some tooling, manual inspection through browser developer tools may be needed to identify what is actually stored. Categorization decisions may require legal input and can vary by jurisdiction.
How is IndexedDB data cleared when a user withdraws consent?
Withdrawal of consent should generally be as easy as giving it, and it is common practice to remove or stop accessing non-essential stored information once consent is withdrawn. For IndexedDB this typically means deleting the relevant databases or object stores programmatically and preventing further non-essential writes. The exact scope of what must be cleared depends on which storage was placed on the basis of consent versus a permitted exemption, which is a fact-specific determination. You should also consider any related personal data processing obligations under the GDPR separately from the device-storage question.
Should IndexedDB usage be included in consent logging and record-keeping?
Where you rely on consent for IndexedDB storage, it is generally advisable that your consent records reflect the purposes for which consent was obtained, consistent with the record-keeping expectations that apply to consent under the GDPR. A consent management platform can support this logging, but a CMP supports compliance rather than guaranteeing it, and it does not replace legal judgment about what storage requires consent. What records are sufficient can depend on your jurisdiction and on evolving guidance from data protection authorities, so the appropriate level of detail may vary.

Common misconceptions

IndexedDB is not a cookie, so cookie consent rules do not apply.
In most EU jurisdictions, the relevant obligation attaches to storing or accessing information on a user's device, not to the specific technology used. IndexedDB used for non-essential purposes generally triggers the same prior-consent considerations under the ePrivacy framework as cookies, though the precise treatment can depend on the facts and applicable national implementation.
Storing data in IndexedDB is purely a technical matter with no privacy implications.
Where IndexedDB stores or is used to retrieve personal data, the GDPR applies to that processing, and the act of storage or access may separately require consent under ePrivacy rules in the EU. Whether a given use is exempt (for example, as strictly necessary) depends on its purpose and is not determined by the technology alone.
Consent obligations for IndexedDB are the same everywhere.
Requirements differ by jurisdiction. EU and UK regimes generally rely on prior opt-in consent for non-essential storage, whereas several US state laws (such as the CCPA and CPRA in California) often operate on an opt-out model. The applicable rules depend on geographic and legal scope.

Best practices

Inventory all IndexedDB usage on your properties alongside cookies and other client-side storage, documenting the purpose of each store so you can assess whether it is strictly necessary or non-essential.
Assess each IndexedDB use against both the ePrivacy question (is information being stored or accessed on the device?) and the GDPR question (is personal data being processed?), treating them as separate obligations rather than assuming one covers the other.
Where IndexedDB is used for non-essential purposes in the EU or UK, obtain prior consent that is freely given, specific, informed, and unambiguous before writing to or reading from it, rather than relying on continued browsing or pre-ticked options.
Configure your consent management platform or equivalent controls so that non-essential IndexedDB operations are gated by consent status and are not initiated before valid consent is captured.
Adapt your approach to the applicable jurisdiction, recognizing that opt-out mechanisms and signals may govern certain US state law contexts while opt-in generally applies in the EU and UK, and confirm scope on a per-market basis.
Seek qualified legal review for contested or fact-dependent uses, and treat tooling as support for compliance rather than a guarantee of it.