Local storage and IndexedDB tracking explained

Most people think of tracking as a cookies problem. Clear your cookies, block third-party cookies, use incognito mode, and you’re supposedly starting fresh. That mental model is out of date. Two storage mechanisms built into every modern browser, localStorage and IndexedDB, can hold onto identifiers long after cookies are gone, and they were never designed with tracking in mind. Understanding how they work matters if you run more than one browser profile for work, because the isolation anti-detect browsers sell is really just isolation of these storage buckets, nothing more mystical than that.

What local storage and IndexedDB actually are

localStorage is a simple key-value store built into every browser. Any website can write string data to it and read it back on a later visit, with no expiration date unless the site or the user clears it. It’s capped at roughly 5-10MB per origin depending on the browser, which is plenty for an identifier.

IndexedDB is a full transactional database sitting inside the browser, also scoped per origin. It can store much larger amounts of structured data, including blobs, and it supports indexes and queries the way a real database does. It was built for offline-capable web apps like email clients and note-taking tools that need to cache real data locally.

Neither one was designed as a tracking tool. But both share a property that makes them attractive for tracking anyway: they persist independently of cookies, they’re not sent automatically with HTTP requests the way cookies are, and until fairly recently browsers did very little to isolate or limit them.

Why trackers moved beyond cookies

Third-party cookie blocking has been rolling out for years now: Safari’s Intelligent Tracking Prevention, Firefox’s Total Cookie Protection, and Chrome phasing out third-party cookies in stages. Once cookies stopped reliably following a user across sites, tracking scripts needed somewhere else to stash an identifier.

localStorage and IndexedDB became part of that toolkit because a script can write a unique ID into them on first visit and read the same ID back on every later visit to that origin, all without a server round-trip. Combine that with other storage locations, cache entries, service worker state, ETags, and you get what’s sometimes called an “evercookie” pattern: the same identifier gets written to five or six places at once, so clearing any one of them doesn’t kill the ID. The script just respawns it from whichever storage location survived.

How IndexedDB becomes a fingerprinting anchor

The more common use case now isn’t storing the whole tracking ID in IndexedDB, it’s using IndexedDB to remember the result of a fingerprint. A site runs its usual collection: canvas rendering, WebGL parameters, audio stack fingerprinting, installed fonts, screen and hardware details, then hashes all of that into a single fingerprint value. On the first visit it writes that hash into IndexedDB. On the next visit it recomputes the fingerprint, checks whether a matching hash already exists in storage, and if it does, treats the visit as a returning user, even if cookies were wiped in between.

This is why clearing cookies alone rarely resets tracking on a site that’s serious about it. The fingerprint itself doesn’t live in a cookie. The cookie was just the easy place to store the pointer to it. Once trackers started keeping that pointer in IndexedDB instead, cookie clearing stopped being a reset button.

Storage partitioning is closing part of this gap

Browser vendors know this, and the fix that’s shipped over the last few years is storage partitioning. Instead of one shared IndexedDB or localStorage bucket per origin, browsers now key storage to the combination of the top-level site and the embedded origin. A tracking script loaded on ten different sites used to be able to read the same IndexedDB entry on all ten. With partitioning, that script gets a separate, empty storage bucket on each site, so the identifier it wrote on site A is invisible on site B.

Safari led on this, Firefox followed with Total Cookie Protection, and Chrome has partitioned storage APIs behind ongoing rollout. This closes the cross-site correlation angle for third-party trackers embedded via iframes or scripts. It does nothing for first-party tracking, where the site you’re directly visiting reads its own IndexedDB to recognize you. If you visit the same site twice in the same browser profile, that site’s own storage and its own fingerprint hash are still sitting there waiting to be matched.

What per-profile isolation in anti-detect browsers actually changes

This is the piece that’s relevant if you’re running multiple accounts on the same platform. Tools like Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty each give you separate browser profiles, and each profile gets its own separate storage: its own localStorage, its own IndexedDB, its own cookie jar, its own cache. Mechanically that’s a real thing happening on disk, not a marketing claim. Profile A’s IndexedDB fingerprint hash is not visible to profile B, because they’re different browser instances with different underlying data directories.

That solves the specific problem this article is about: a platform can’t use IndexedDB to link your second account back to your first purely through shared storage, as long as the profiles stay genuinely separate and you’re not logging into both from the same physical machine session in ways that leak elsewhere.

What it doesn’t change

Storage isolation says nothing about the other fingerprinting surfaces a platform can check independently of what’s sitting in IndexedDB. Canvas and WebGL rendering fingerprints, font lists, screen resolution and hardware concurrency, timezone versus IP location mismatches, TLS and HTTP/2 handshake ordering, and behavioral signals like typing cadence or mouse movement all exist outside of storage entirely. A platform doesn’t need to read your IndexedDB to notice that five “different” profiles all report the same GPU renderer string, the same installed font set, and connect from IP ranges that belong to the same hosting provider.

This is the gap between what storage isolation solves and what people sometimes assume it solves. No anti-detect browser makes a profile undetectable or a platform blind to it, and none of the tools listed above should be taken as unbannable just because their storage isolation is doing its job correctly. Storage isolation removes one specific correlation vector. Platforms that care about multi-accounting are looking at a lot more than that vector, and detection teams update what they check for on their own schedule, not on ours.

Where this actually matters for day to day use

If you’re running a real proxy setup and separate profiles for legitimate multi-account work, the practical takeaway is to treat storage isolation as necessary but not sufficient. Pair it with proxies that actually match the profile’s claimed location and hardware fingerprint, don’t share resources like fonts installs or GPU drivers that would make separate profiles look identical at the rendering layer, and don’t assume that because IndexedDB is clean, everything else is too. The browser vendors are still tightening partitioning rules, and that trend is only going to continue.

If you want to go deeper on how canvas and WebGL fingerprinting work, or want a plain look at how these anti-detect tools compare on the mechanics that actually matter, that’s what we dig into on the rest of the site here.

Get new guides and videos first — join the Telegram channel.