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.
• HTTP Strict Transport Security (HSTS) pin tokens. Specifically named in the EDPB’s 02/2023 examples as a technique that, if used as a tracking primitive, falls under 5(3).
• 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 intent, not transport.

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 CNIL has issued sanctions on localStorage-based tracking. The Italian Garante has done the same. The Bavarian DPA published guidance specifically warning against this pattern in 2023.

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

Veracly captures the complete storage state on first load — cookies, localStorage, sessionStorage, IndexedDB, Service Worker registration, Cache API entries, fingerprinting telemetry detected via runtime instrumentation. Every entry is evaluated against the same 5(3) test and flagged in the report when consent was not obtained first. The audit is technology-neutral because the law is.

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