Why the cookie rule covers them
Article 5(3) is written about storing information in, or gaining access to information already stored in, the terminal equipment of a subscriber or user. It never says "cookie". localStorage, sessionStorage, IndexedDB and cache-based identifiers are all storage on the device, and they are all inside the rule.
A great deal of modern tracking has moved into exactly these APIs, partly because cookie restrictions pushed it there. An audit that reads only the cookie jar will report a site as clean while an analytics SDK keeps its identifier in localStorage.
Finding it
This is one of the reasons StrongPrivacy scans in a real browser rather than parsing source. The scan inspects cookies, local and session storage, scripts, frames and outbound requests, in each consent state, and reports what was present before any choice was made.
Common questions
Does localStorage require consent?
If what it holds is not strictly necessary for a service the visitor requested, yes, on the same basis as a cookie. The storage mechanism is not what the rule turns on.
Is sessionStorage exempt because it is temporary?
Not automatically. Duration is relevant to proportionality, not to whether the rule applies. A session-scoped tracking identifier is still an identifier.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- ICO: guidance on storage and access technologies
Regulator guidance
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.