Why a fingerprint-based visitor ID survives cookie clears, private mode, and VPNs — and which signals actually make it stick.
Clear your cookies, open a private window, switch on a VPN — and plenty of sites still know it's you. That isn't a bug. A persistent visitor ID is usually not a file stored on your device at all; it's a value recomputed each visit from characteristics of your browser and hardware, so there is nothing to delete.
Key Takeaways
- A persistent visitor ID is typically derived from stable device/browser signals (canvas, WebGL, fonts, hardware), not stored in a cookie — so there's nothing for "clear browsing data" to remove.
- Incognito and private windows wipe local storage but leave your rendering fingerprint untouched, so a site can still recognize the same underlying device.
- A VPN changes your IP address, not your browser or hardware — the fingerprint that anchors the ID doesn't move with it.
- Some tracking scripts deliberately duplicate an ID across cookies, localStorage, IndexedDB, and cache-based stores so that deleting any one copy doesn't reset it — a technique known as respawning.
- You can test your own resilience: run a fingerprint check before and after clearing data, going incognito, or connecting to a VPN, and compare the ID.
Two very different kinds of "visitor ID"
Not all visitor IDs are built the same way, and the distinction explains why clearing your browser sometimes resets tracking and sometimes doesn't.
A storage-based ID is a random value a server generates once and writes into a cookie, localStorage, or a similar client-side store. It survives exactly as long as that storage does — delete the cookie, and the ID is gone. This is the kind most privacy tools are built to fight, and it's why "clear cookies" used to be reasonably effective advice.
A fingerprint-derived ID is different: instead of writing a value to your device, the site computes a hash from things your browser and hardware already reveal — canvas rendering, WebGL renderer strings, installed fonts, screen and hardware-concurrency values, audio processing quirks, and more. See our browser fingerprinting guide for the full signal list and why combining enough of them makes most browsers close to unique. Because none of this is written to storage, there's nothing on your device that "clear browsing data" can touch. The ID isn't stored — it's recognized again on your next visit, from the same inputs.
Commercial identity and anti-fraud vendors (Fingerprint's visitorId is a well-known example of the pattern) lean on exactly this property: a stable identifier that keeps matching the same device across sessions specifically because it isn't sitting in a cookie jar waiting to be emptied.
Which signals actually survive clearing
Not every fingerprint input is equally durable. A useful mental split is what you can flip with a setting versus what comes from hardware and drivers:
| Signal | Survives cookie/storage clear? | Why |
|---|---|---|
| Canvas & WebGL hash | Yes | Derived from GPU/driver rendering, not stored data |
| Installed font list | Yes | Comes from the OS, not the browser's storage |
| Audio fingerprint | Yes | Derived from the audio stack's signal processing |
| Hardware concurrency, screen metrics | Yes | Read live from the device each time |
| Cookies, localStorage, IndexedDB | No (by default) | Explicitly wiped by "clear browsing data" |
| Cache-based supercookies | Often, unless cache is also cleared | Piggybacks on caching behavior, not the storage APIs a "clear data" button targets |
The rendering and hardware signals are the ones that make a fingerprint-derived ID persistent, because they're recomputed from the device itself rather than read back from a file. That's also why they're the hardest to defend against — you can't "delete" your GPU's rendering quirks the way you delete a cookie.
Supercookies: making a storage-based ID persistent on purpose
Some tracking scripts go further and deliberately fight back against clearing. The technique — often called respawning — writes the same ID into several independent stores at once: a cookie, localStorage, IndexedDB, and even HTTP caching mechanics like ETag values, which a server can echo back to silently confirm a returning client. If you clear cookies but leave the cache alone, the script reads the surviving copy and rewrites it into the stores you just cleared.
evercookie, a well-known proof-of-concept by security researcher Samy Kamkar, demonstrates the idea by storing an identifier redundantly across as many browser storage mechanisms as it can reach, specifically so that clearing any single one leaves the ID recoverable from the rest. It's a useful reference for understanding why "clear cookies" alone was never a complete defense, even before fingerprinting made storage unnecessary in the first place.
Browsers have pushed back with mechanisms built to remove all of a site's stored data in one action — see MDN's Clear-Site-Data header, which lets a site (or a privacy-conscious browser setting) instruct the browser to wipe cookies, cache, and storage for that origin together, closing the gap that respawning exploits. It does nothing, however, for the fingerprint-derived kind of ID described above — there's no "site data" to clear when the identifier was never stored.
Why incognito mode doesn't reset it
Private browsing modes are built to solve a local problem: don't leave a trace on this device after the window closes. They isolate cookies and storage into a throwaway container that's discarded on close, which is exactly why storage-based IDs reset in a fresh private window.
But your canvas rendering, WebGL renderer string, font list, and hardware characteristics don't change because you opened a private tab — they come from the same GPU, OS, and installed software either way. A site relying on a fingerprint-derived ID sees the same signals in incognito as in your normal window, and can link the two sessions together as the same visitor. Some sites go a step further and actively detect that you're in private mode at all, usually through quirks in storage-quota APIs — see how sites detect incognito and private browsing for the mechanics.
Why a VPN doesn't reset it either
A VPN operates purely at the network layer: it changes the IP address a server sees and, usually, the apparent geographic location. That's genuinely useful against IP-based tracking and geolocation, but it has no effect on anything the browser or device reports about itself. Your canvas hash, WebGL renderer, fonts, and screen metrics travel through the VPN tunnel completely unchanged, because a VPN never touches the browser process generating them.
So switching servers or providers doesn't give you a "new" fingerprint-derived ID — only a new IP tied to the same underlying device signals. If anything, an IP that jumps between countries every few minutes while the rest of the fingerprint stays constant is itself a pattern some anti-fraud systems flag as suspicious.
The privacy trade-off
Persistent visitor IDs aren't purely adversarial — the same properties that make them hard to clear also make them useful for fraud prevention and account-abuse detection, where a service wants to recognize a returning device even if it lies about its cookies. The trade-off is that the exact same mechanism, aimed at an ordinary visitor rather than a fraudster, becomes cross-session tracking that ordinary privacy controls (clearing cookies, going incognito, using a VPN) can't touch.
That asymmetry is why "I cleared my history" is poor evidence of a fresh start, and why the meaningful defenses are the ones that change the signals themselves — a uniform-fingerprint browser like Tor, or a randomizing one like Brave — rather than the storage those signals get written to. Our browser fingerprinting guide covers both approaches in more depth, and extensions are worth scrutinizing too, since a careless one can add its own tracking surface — see browser extension privacy risks before installing anything new.
How to test your own resilience
The fastest way to see whether your setup actually resists persistent IDs is to compare it against itself:
- Run BrowserInsight's fingerprint check in your normal browser and note the canvas/WebGL/audio values and the overall anonymity score.
- Clear all site data, then reload the check. If the same hash values reappear, they were never stored to begin with — they were recomputed from your device.
- Repeat in a private/incognito window, and again with a VPN connected. If the values still match your first run, the underlying fingerprint — and any ID built on it — hasn't changed.
Because everything runs client-side in your own browser, none of this data ever leaves your device during the test.
Frequently Asked Questions
Does clearing cookies remove a fingerprint-based visitor ID?
No. A fingerprint-derived ID isn't stored anywhere on your device — it's recalculated from your browser and hardware characteristics each time you're seen. Clearing cookies, cache, or site data has nothing to delete.
Can a VPN give me a fresh visitor ID?
No. A VPN changes your IP address, not your browser or device. A fingerprint-derived ID is built from rendering, font, and hardware signals that pass through a VPN tunnel unchanged.
Is incognito mode useless against fingerprinting?
Not useless, but limited. It reliably clears local storage-based IDs when the window closes, but it does not alter the rendering and hardware signals a fingerprint-derived ID relies on, so those can still link an incognito session to your normal one.
What actually stops a persistent visitor ID?
Changing the underlying signals, not the storage. A browser that standardizes its fingerprint (like Tor) or randomizes it per session (like Brave) removes the stable inputs an ID depends on. Clearing cookies alone does not.
Conclusion
A persistent visitor ID that survives cookie clears, incognito mode, and a VPN isn't a bypass of your privacy controls — it's simply built from a different layer than those controls reach. Storage-based IDs live in cookies and respond to "clear browsing data"; fingerprint-derived IDs live in your device's rendering and hardware characteristics and get recomputed on every visit. Knowing which kind you're dealing with is the first step to defending against it — and checking your own fingerprint before and after each defense is the only way to know if it actually worked.
Recommended Reading:
