Cookies vs localStorage vs IndexedDB: which require consent?

A persistent misconception in cookie compliance: that swapping cookies for localStorage somehow escapes the consent obligation. It does not. The ePrivacy storage rule is technology-neutral, the EDPB and national DPAs have been explicit about this for years, and the only thing that changes when a developer migrates from cookies to localStorage is the inspection tool used to find the violation.

What Article 5(3) actually says

Directive 2002/58/EC, Article 5(3) (as amended in 2009):

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent...

Three things in this text are worth re-reading. “Storing of information” is not storing of cookies. “Gaining of access to information already stored” covers reading device properties, not just reading what you wrote. “Terminal equipment” is the user’s device, anything you put there or read from it.

What this covers in practice

The current consensus position (German DSK guidance December 2021; EDPB Guidelines 02/2023 on the technical scope of Article 5(3); CNIL position papers; national implementations of the ePrivacy Directive across all 27 member states):

• HTTP cookies. First-party, third-party, session, persistent, all covered.
• HSTS supercookies. The per-host HSTS state a browser persists after a Strict-Transport-Security header can be used as a tracking primitive, and read that way it is information stored on and retrieved from terminal equipment, so 5(3) engages. This is not an inference: EDPB Guidelines 02/2023 name HSTS explicitly at paragraph 43 and footnote 26, alongside ETag.
• localStorage and sessionStorage. Web Storage API entries.
• IndexedDB. Structured client-side database entries.
• Service Worker caches, Cache API entries. Service-worker-controlled caches that persist after browser close.
• File System Access API entries. When used to persist client data.
• Web SQL Database (deprecated but still seen on old codebases).
• Web Beacon / 1×1 pixel requests that write identifiers.
• ETag and Last-Modified cache headers when used as a tracking primitive (the EDPB explicitly covers cache-based identification techniques).
• Browser fingerprinting. Canvas fingerprinting, audio fingerprinting, font enumeration, WebRTC IP detection, covered as “gaining access to information already stored” on the device, even without writing anything.

What this excludes

Server-side processing of data the user voluntarily submitted (a contact form, a checkout) does not trigger 5(3) because no storage on the user’s device occurs. That is GDPR territory, not ePrivacy 5(3). The line is whether the user’s terminal equipment is involved as a storage or readout site.

HTTP request headers the browser sends automatically (User-Agent, Accept-Language, Sec-CH-UA hints) are also outside 5(3) when used in their intended functional capacity. The moment those headers are combined to fingerprint a user, 5(3) re-engages. The EDPB’s test is neither intent nor transport but instruction: whether the entity instructed the terminal equipment to send the information (Guidelines 02/2023, paras 33–34). The same paragraphs make clear the entity that issues the instruction and the entity that receives the information need not be the same, so “we never wrote the code, we only receive the data” is not an answer.

The “localStorage trick” that does not work

A pattern Veracly sees in the wild: a developer reads the cookie-consent law, assumes it is cookie-specific, and switches the analytics tracker to write its identifier to localStorage instead of a cookie. The CMP banner is removed because “we do not set cookies anymore.”

This is legally identical to the original cookie deployment. The storage event is the trigger; the storage mechanism is not. The argument does not need an enforcement record to stand on, which is just as well: a regulator reading Article 5(3) against a localStorage identifier arrives at the same place it arrives for a cookie, and there is nothing in the wording to push back with.

The practical consequence: a Veracly scan flags localStorage entries and IndexedDB keys the same way it flags cookies. The report’s storage inventory is not cookie-only.

How to audit your site

1. Open DevTools, hard-reload the page (Cmd-Shift-R / Ctrl-Shift-R).
2. In the Application tab, expand Storage. Check Cookies, Local Storage, Session Storage, IndexedDB, Web SQL, Cache Storage.
3. For each entry, ask: is this strictly necessary for the service the user requested? If no, ePrivacy 5(3) consent is required before the entry was written.
4. Repeat after consent acceptance. Many sites that look clean pre-consent re-introduce trackers post-consent, which is correct as long as the trackers fired only after the consent click.
5. Repeat after consent rejection. Some sites continue to fire trackers even when the user clicked reject. This is a hard violation under both ePrivacy 5(3) and GDPR Article 7.

Veracly’s scope, precisely

Worth being exact about what is captured. On first load, before any interaction with a consent banner, Veracly records cookies from the whole browser context — which is why cookies set inside a cross-origin iframe are caught too, though a cookie carries only its name and domain, with no frame attached to it. Web Storage and IndexedDB are read per frame, and those entries do carry the URL of the frame that wrote them, so an embed’s localStorage is attributable. Anything written before consent surfaces as a pre-consent cookie or pre-consent storage-write finding, evaluated against the same 5(3) test as a cookie, because the law makes no distinction.

Two hard limits on that. First, we record keys and database names only, never values. A Veracly report cannot leak the contents of your users’ storage because it never reads them. Second, that list is the whole list: there is no Service Worker registration check, no Cache API enumeration, and no fingerprinting detection of any kind — no canvas, audio, WebGL or font-enumeration instrumentation. The earlier version of this post claimed all three. None of them are real, and the fingerprinting gap is a genuine one worth naming: canvas fingerprinting sits squarely inside Article 5(3), and we cannot see it.

The scanner also never clicks your banner. Clicking Accept or Reject would itself be a consent gesture and would pollute the pre-consent reading, which is the measurement we care most about getting right. That is a deliberate trade, and its cost is that steps 4 and 5 of the manual audit above are yours to run — there is no post-consent pass. Run a scan.

See also: GDPR vs ePrivacy: which one governs cookies? · Heat maps and session recordings: the legitimate interest grey area