Browser Storage Fingerprinting: How localStorage Tracks You | whatsmy.fyi

Browser storage fingerprinting is a tracking technique that plants persistent identifiers inside your browser's own storage — localStorage, sessionStorage, IndexedDB, and cookies — and then reads them back on every return visit. Unlike hardware-level fingerprinting, storage fingerprinting survives cookie deletion by spreading across multiple storage layers simultaneously. You can check what your browser currently exposes on whatsmy.fyi.

TL;DR

Browser storage fingerprinting works by writing a unique identifier into localStorage, sessionStorage, IndexedDB, and cookies simultaneously. When you delete one, the tracker reconstructs it from the others. Techniques like Evercookie extend this across 16+ storage vectors, making the identifier nearly impossible to erase without specialised tools. Modern browsers counter this with storage partitioning — isolating each storage bucket per top-level domain so cross-site tracking becomes structurally impossible.

What Is Browser Storage Fingerprinting?

Browser storage fingerprinting is a category of browser fingerprinting that exploits the browser's built-in storage APIs rather than hardware signals like GPU rendering or audio processing. The goal is the same — uniquely identify your device across sessions and websites — but the mechanism is different: trackers write data to your browser's own storage and read it back on subsequent visits.

What separates storage fingerprinting from a simple tracking cookie is redundancy. A traditional cookie is a single storage slot. Storage fingerprinting writes the same identifier to a dozen different storage mechanisms simultaneously. When you clear cookies, the identifier survives in localStorage. When you clear localStorage, it survives in IndexedDB. When you clear IndexedDB, the tracker reads whichever vector still holds data and rewrites all the others. The Electronic Frontier Foundation's Cover Your Tracks tool identifies storage-based resurrection as one of the hardest tracking techniques for ordinary users to neutralise.

How Does Browser Storage Fingerprinting Work?

Storage fingerprinting follows a read-write loop across four primary browser storage mechanisms, each with different persistence characteristics.

Step 1 — Generating the Identifier

On the first visit, a JavaScript script generates a unique identifier — typically a random UUID or a hash of hardware signals collected at the same time. This identifier is then written simultaneously to every available storage vector.

Step 2 — Writing to Multiple Storage Layers

The same ID is stored in localStorage (persistent, origin-scoped), sessionStorage (tab-scoped, clears on tab close), IndexedDB (structured database, larger quota), and HTTP cookies (sent with every request, accessible server-side). Advanced implementations also write to ETags, HSTS entries, browser cache, and window.name — which persists across page navigations within the same tab.

// Simplified multi-vector storage write
const trackingId = crypto.randomUUID();

// Persistent — survives browser restarts, cookie deletion
localStorage.setItem('_tid', trackingId);

// Tab-scoped — survives navigation within the tab
sessionStorage.setItem('_tid', trackingId);

// IndexedDB — structured, larger storage quota
const db = await openDB('tracker', 1, {
  upgrade(db) { db.createObjectStore('ids'); }
});
await db.put('ids', trackingId, 'primary');

// HTTP cookie — server-readable, cross-request
document.cookie = `_tid=${trackingId}; max-age=31536000; SameSite=Lax`;

Step 3 — Reading Back on Return Visits

On the next visit, the script reads all four storage layers. If any one of them still holds the ID, the user is recognised. If some vectors were cleared, those are immediately rewritten from the surviving values — a technique called cookie resurrection. From the tracker's perspective, the user's identity is recovered as long as at least one storage layer survived.

Step 4 — The IndexedDB Ordering Side Channel

Beyond simple read-write tracking, a subtler vulnerability was discovered in 2025 and documented by Fingerprint.com researchers. The indexedDB.databases() API in Firefox returned database names in a non-random order determined by an internal hash table — a process-scoped side channel. Unrelated websites could call this API independently and observe the same ordering, linking a user across different origins without reading or writing any actual storage data. The vulnerability (CVE-2026-6770) was patched in Firefox 150 and Tor Browser 15.0.10 by canonicalising results into alphabetical order before returning them.

Evercookie: The Extreme Case

Evercookie is a proof-of-concept library created by security researcher Samy Kamkar that demonstrates the full extent of storage-based resurrection. It simultaneously stores an identifier across 16 or more vectors: HTTP cookies, localStorage, sessionStorage, IndexedDB, Web SQL Database, Flash Local Shared Objects, Silverlight Isolated Storage, CSS history, ETags, browser cache, HSTS headers, window.name, PNG pixel encoding, and Java applet storage. When any subset of these is deleted, the library reconstructs the full identifier from whichever vectors survived. In 2014, IndexedDB-based Evercookie techniques were detected on weibo.com in production, marking the first commercially confirmed use of this approach.

Storage Fingerprinting Statistics

The gap between desktop and mobile accuracy exists because mobile devices are far more homogeneous — millions of users share identical hardware and OS versions. Desktop machines with varied GPU drivers, installed applications, and font libraries produce much more distinctive storage and hardware profiles.

Who Uses Browser Storage Fingerprinting in the Real World?

Advertising and Retargeting Networks

Ad-tech companies use storage-based identifiers to link a user's browsing activity across different websites without relying on third-party cookies, which are blocked by default in Firefox and Safari and deprecated in Chrome. A shared localStorage key or IndexedDB record inside a third-party iframe achieves the same cross-site identification as a third-party cookie — unless the browser applies storage partitioning.

Fraud Detection and Account Security

Fraud prevention platforms use multi-vector storage to create a stable device fingerprint for recognising returning customers and flagging device changes. If an account login comes from a device whose storage fingerprint does not match any prior session for that account, it is flagged for additional verification. This use case is typically permissible under GDPR's legitimate interest basis without requiring explicit consent.

Paywall and Metered Content Enforcement

News publishers that offer free article limits use storage fingerprinting to prevent users from bypassing their meter by clearing cookies. Because the article-count identifier is written to localStorage and IndexedDB simultaneously, clearing cookies alone does not reset the counter. Only clearing all site data from the browser's developer tools resets the meter — and even then, only until the next visit writes the identifier back.

Analytics and Session Reconstruction

Some analytics platforms use localStorage-based session tokens to stitch together user journeys across multiple page loads, even when the user navigates away and returns minutes later. This is more persistent than sessionStorage (which clears when the tab closes) and more reliable than cookies (which the browser may not send in some cross-site contexts).

Is Browser Storage Fingerprinting Legal?

Under GDPR in Europe, any data that can be used to identify an individual — including device identifiers stored in localStorage or IndexedDB — constitutes personal data. The UK Information Commissioner's Office confirmed in January 2025 draft guidance that localStorage, sessionStorage, and IndexedDB fall under the same PECR rules as cookies, requiring informed consent or a narrow legitimate interest justification. The French data protection authority (CNIL) has reached the same conclusion, naming browser storage as a tracking vector subject to prior consent requirements. Under the US CCPA and CPRA, storage-based device identifiers are treated as personal information with opt-out rights. Enforcement remains inconsistent globally, but the regulatory direction is clear: storage tracking without disclosure is legally equivalent to cookie tracking without a banner.

The W3C Fingerprinting Guidance classifies localStorage-style persistence as "cookie-like fingerprinting" — the most direct category of tracking — and recommends that specification authors consider how storage APIs can be partitioned or restricted to reduce the fingerprinting surface available to scripts.

How to Protect Yourself from Browser Storage Fingerprinting

Unlike hardware fingerprinting, storage fingerprinting can be structurally defeated — but only with browser-level controls, not just clearing history.

• Enable Total Cookie Protection (Firefox): Firefox's Enhanced Tracking Protection in Strict mode activates state partitioning — each website gets its own isolated storage bucket. A tracker's localStorage entry set inside foo.com cannot be read when the same tracker loads inside bar.com. This is the single most effective protection against cross-site storage tracking and is enabled by default in Firefox in Standard mode for known trackers.
• Use Safari (any version with ITP): Safari's Intelligent Tracking Prevention partitions localStorage, IndexedDB, Cache API, and Blob URL storage by top-level site, and proactively evicts storage data from origins that have had no user interaction for 7 days. Storage-based cross-site tracking is structurally blocked by default.
• Use Brave Browser: Brave blocks fingerprinting by default, applies storage partitioning, and allows per-site customisation. Its Shields panel gives you granular control over which tracking vectors are allowed.
• Clear All Site Data, Not Just Cookies: Browser history deletion typically clears cookies but leaves localStorage and IndexedDB intact. In Chrome and Firefox, use the developer tools (Application tab → Storage → Clear site data) or the browser's "Clear browsing data" menu with the "Cached images, cookies and other site data" option to clear all storage at once.
• Use a Container Extension (Firefox Multi-Account Containers): Firefox containers isolate each container's storage from every other container. Running social media in one container and general browsing in another prevents social trackers from reading localStorage values set during your general browsing.
• Tor Browser (strongest protection): Tor Browser clears all storage on every "New Identity" action, applies storage partitioning, and uses a uniform browser profile shared by all Tor users. Note that the IndexedDB ordering vulnerability (CVE-2026-6770) described above affected Tor Browser before version 15.0.10; update to the current version if using Tor.
• Disable third-party iframes / JavaScript selectively: Most cross-site storage tracking operates via third-party scripts loaded inside iframes. uBlock Origin in medium mode blocks most of these vectors by preventing third-party scripts from loading entirely. This is the most aggressive approach and breaks some embedded content.

Frequently Asked Questions

Is clearing cookies enough to prevent storage fingerprinting?

No. Clearing cookies is the minimum step, not a complete solution. Storage fingerprinting deliberately spreads the identifier across localStorage, sessionStorage, IndexedDB, and cookies simultaneously. Clearing only cookies leaves the identifier intact in the other three vectors. On the next visit, the tracker reads the surviving copy and rewrites the cookie. You must clear all site data — not just cookies — to remove a storage-based identifier, and even then, the tracker will recreate it the next time you visit the site.

Does incognito or private mode protect against storage fingerprinting?

Partially. Private mode creates a fresh, isolated storage context that is entirely wiped when the private window closes. Any localStorage, IndexedDB, or cookie written during a private session does not persist to your main profile. However, within a single private session, storage fingerprinting works normally. A tracker can still identify you across multiple tabs inside the same private window. For cross-session protection, private mode is effective — but it does not protect against hardware-level fingerprinting, since your GPU, fonts, and canvas output are identical in private and normal mode. See the canvas fingerprinting guide for why hardware signals are harder to defeat.

What is the difference between localStorage and sessionStorage?

Both APIs expose the same interface (setItem, getItem,removeItem), but their persistence differs. localStorage persists until explicitly cleared, survives browser restarts, and is shared across all tabs for the same origin. sessionStorage is isolated to the current tab and is automatically deleted when the tab closes. For tracking purposes, localStorage is the higher-value vector because it survives across multiple sessions. sessionStorage is primarily used to link page views within a single user journey, not for long-term identification.

What makes IndexedDB more dangerous than localStorage for tracking?

IndexedDB supports structured data with larger storage quotas (typically 80% of available disk space versus a few megabytes for localStorage). More importantly, the 2025 IndexedDB ordering vulnerability demonstrated that IndexedDB can be exploited as a side channel even without reading or writing tracking data — the internal ordering of database names was itself a stable identifier that could be observed by unrelated origins. localStorage has no equivalent structurally derived side channel. The vulnerability was patched in Firefox 150 and Tor Browser 15.0.10.

Can a VPN prevent browser storage fingerprinting?

No. A VPN routes your traffic through an encrypted tunnel and changes your visible IP address, but it has no access to your browser's storage. The JavaScript running in your browser reads and writes localStorage and IndexedDB entirely locally — no network traffic is involved in the read step. A VPN is effective against IP-based geolocation tracking but provides zero protection against storage-based or hardware-based fingerprinting. Check whether your VPN is working correctly on whatsmy.fyi.

How is storage fingerprinting related to canvas or WebGL fingerprinting?

Storage fingerprinting and canvas fingerprinting represent two ends of the tracking spectrum. Storage fingerprinting is "cookie-like" — it writes something to your device and reads it back. Canvas and WebGL fingerprinting are "stateless" — they reconstruct your identity from hardware characteristics without storing anything. Commercial tracking platforms layer both approaches: storage gives them a fast, stable ID; hardware fingerprinting lets them re-identify you even after a full storage wipe. The combination is far more resilient than either technique alone.

Is localStorage fingerprinting legal under GDPR?

Under GDPR and PECR (in the UK), accessing or storing information on a user's device — including via localStorage, sessionStorage, and IndexedDB — requires either informed consent or a narrow legitimate interest justification. The UK ICO's January 2025 draft guidance explicitly named these APIs as falling under the same rules as cookies. In practice, many smaller publishers deploy localStorage-based trackers without disclosure, assuming these mechanisms escape the legal requirements that cookie banners satisfy. That assumption is increasingly incorrect, and enforcement actions have begun to treat all storage-based tracking consistently with cookie tracking.

Related Articles

• What Is Browser Fingerprinting? How Sites Track You Without Cookies — the complete guide to all fingerprinting signals combined, including both storage and hardware vectors
• What Is Canvas Fingerprinting? How Websites Track You Without Cookies — how the HTML5 Canvas API produces a device-unique pixel hash from your GPU and font renderer
• What Is WebGL Fingerprinting? How Your GPU Identifies Your Browser — how the 3D graphics API exposes your GPU vendor name, model, and driver version
• What Is Audio Fingerprinting? How AudioContext Tracks Your Browser — how your device's audio processing stack produces a hardware-level identifier