How do websites remember you?

Websites remember you through five overlapping mechanisms: cookies, browser fingerprinting, cache- and header-based supercookies, DNS-level CNAME cloaking, and local device storage. No single one of these is "the" tracking method anymore — sites layer two or three together so that killing one, say by clearing your cookies, doesn't reset your identity, because a fingerprint or a cache-based ID survives underneath it.

Quick reference: the five mechanisms

Here's what actually survives what — this is the part most explainers skip, since they describe cookies in isolation as if 2026 tracking still looked like 2010 tracking.

Cookies: still the default, not the dying technology you've read about

A cookie is a small text file a website asks your browser to store, then sends back with every subsequent request to that same domain. First-party cookies — set by the site you're actually on, keeping you logged in or remembering your cart — are functionally necessary. Third-party cookies — set by a domain other than the one in your address bar, like an ad network embedded across ten thousand unrelated sites — are what let advertisers recognize you as you move between them.

Here's the part that's actually current, and where most 2025-dated "cookies are dying" articles are now wrong: Google reversed course. Chrome was supposed to phase out third-party cookies by 2022, then 2024, then 2025. In April 2025, Google announced it wasn't going to deprecate them at all, and by October 2025 it had shut down most of the Privacy Sandbox APIs it spent six years building as the replacement. Third-party cookies are still on by default in Chrome as of mid-2026 — Chrome simply doesn't force the issue the way Safari and Firefox do.

Safari's Intelligent Tracking Prevention and Firefox's Enhanced Tracking Protection have blocked third-party cookies by default for years, and Brave does the same. Those three browsers alone put roughly a fifth of global traffic outside third-party cookie tracking, regardless of anything Chrome does — which is exactly why the mechanisms below exist. They're what advertisers built to keep working on the browsers that already block cookies.

Browser fingerprinting: the part that survives everything

A browser fingerprint doesn't store anything on your device — it recognizes your device by measuring how it renders things. Every combination of GPU, driver version, and font rendering engine produces microscopic differences when your browser draws a canvas element or processes an audio signal. Two visually identical images, rendered on two different machines, hash to different values. That hash becomes your ID, and clearing cookies does nothing to it.

Canvas fingerprinting asks your browser to silently draw a hidden shape or string of text, then reads the resulting pixel data back and hashes it. A 2025 ACM Internet Measurement Conference study found canvas fingerprinting active on 12.7% of the top 20,000 websites — up from the 5.7% a Princeton study measured across the Alexa top 100K back in 2014, meaning adoption roughly doubled over a decade rather than fading as cookie alternatives matured. Run our own canvas fingerprint test to see what this specific technique reveals about your browser.

AudioContext fingerprinting does the same thing with sound: it renders an audio signal through the Web Audio API and reads the output waveform, which varies by sound card, OS audio stack, and CPU architecture, without ever producing audible sound. It's a quieter sibling to canvas fingerprinting, increasingly stacked alongside it rather than used on its own.

The edge case most articles miss: fingerprinting isn't only used for advertising. Bot detection vendors like Cloudflare, Akamai, and PerimeterX (HUMAN Security) use canvas and WebGL fingerprints specifically to catch automation — a Chrome user-agent string paired with a rendering pipeline that actually matches Firefox's Skia renderer is a mismatch that triggers a CAPTCHA challenge, independent of anything related to ads. Fingerprint randomization and fingerprint spoofing have opposite risk profiles against this kind of detection: a browser that randomizes its own values (Brave's approach) looks consistently unusual in a way fraud systems tolerate, while a tool that spoofs a specific different device's fingerprint can produce an "impossible" hardware/software combination, which is exactly the kind of mismatch fraud detection is built to flag.

A case study in why new browser APIs get killed: in 2015, researchers demonstrated that the Battery Status API — a W3C feature meant to let sites dim the screen when a laptop ran low on power — exposed battery charge level precisely enough (down to hundredths of a percent) to work as a short-lived cross-site tracking identifier, since that decimal value was almost never identical between two users at the same moment. The disclosure led Firefox to remove the API entirely in 2016, and it's still the reference case privacy engineers cite when arguing that a new browser API needs a fingerprinting threat assessment before it ships, not after.

Fingerprint uniqueness also varies enormously by browser choice. EFF's Cover Your Tracks project puts Tor Browser's fingerprint uniqueness under 5% — nearly everyone running Tor looks identical — versus roughly 83% for a stock Chrome install, which makes browser choice the single largest lever an individual has over their own trackability, bigger than any extension. Run our own browser fingerprint test to see where your current setup falls on that scale.

Supercookies: the ones that live outside the cookie jar entirely

"Supercookie" gets used loosely, but the useful definition is: any identifier that survives a normal cookie clear because it isn't stored where cookies are stored.

The clearest real-world case is Verizon's UIDH program. Starting in 2012, Verizon Wireless injected a Unique Identifier Header directly into its subscribers' unencrypted HTTP traffic at the network level — not something the browser set, but something the carrier inserted into every request as it passed through Verizon's own infrastructure. Users couldn't see it or delete it, and Verizon didn't disclose the practice for two years. The FCC's investigation found that at least one Verizon ad partner used the header specifically to reconstruct tracking cookies that users had deliberately deleted — the exact "rebuild identity after it's cleared" behavior that defines an evercookie. Verizon paid a $1.35 million FCC fine in March 2016 and was required to get opt-in consent before sharing the header with third parties going forward.

Cache and ETag-based tracking works differently but hits the same problem. HTTP caching headers (ETags, Last-Modified) are designed to let a server recognize "you already have this exact file, don't re-download it." A tracker can assign each visitor a unique ETag value for an otherwise-identical cached resource — a 1x1 pixel image, a font file — and every time your browser asks "do I still have the current version of this?", it re-sends that unique value. Clearing cookies doesn't touch the browser cache, so the identifier persists until the user clears the cache specifically — something far fewer people know to do than "clear cookies."

CNAME cloaking: making third-party trackers look first-party

This one is a DNS trick, not a cookie trick, and it exists specifically to defeat the browsers that block third-party cookies. A site sets up a subdomain — say stats.example.com — and instead of pointing it at their own server, points it via a CNAME DNS record at a tracking company's infrastructure. To your browser, a request to stats.example.com looks completely first-party, because it shares the same domain as the site you're on. The tracker sets what appears to be a first-party cookie, and Safari's ITP or Firefox's ETP — both built to block third-party cookies specifically — let it straight through.

A 2021 KU Leuven study found this technique in use on nearly 10% of the top 10,000 websites, growing 21% over the prior 22 months, and documented that ad-tech company Criteo specifically switched to CNAME cloaking as a targeted workaround when it detected Safari users — a direct, named example of a company adapting its tracking method in response to a specific browser's privacy feature.

Local storage, IndexedDB, and "evercookies"

Cookies aren't the only place a browser stores data. localStorage and IndexedDB are larger, more persistent JavaScript-accessible storage APIs originally built for legitimate web apps to save state offline. Nothing stops a tracker from writing the same identifier into five or six of these storage locations simultaneously — localStorage, IndexedDB, a cache-stored ETag, a cookie — so that clearing any one still leaves the ID intact in the others. When the site notices one copy is missing, it just respawns it from whichever location survived. This "respawning" behavior is the actual technical definition of an evercookie, a term often used loosely to mean "any hard-to-delete tracker" but originally referring specifically to this multi-location, self-healing redundancy.

Where this actually leaves you

None of these mechanisms are defeated by a single fix — that's the point of layering them. A cookie-clearing extension does nothing to a canvas fingerprint. A VPN changes your IP but not your GPU's rendering signature. Blocking third-party cookies is exactly what pushed advertisers toward CNAME cloaking and fingerprinting in the first place. The realistic posture is matching defenses to mechanisms, since no single setting or extension covers all five at once:

• Against fingerprinting — use a fingerprint-resistant browser (Tor Browser or Brave), not a cookie-clearing extension, which has no effect on canvas or audio fingerprinting at all.
• Against ETag/cache-based supercookies — clear your browser cache alongside cookies, not just cookies, since the ETag identifier lives in the cache specifically.
• Against CNAME cloaking — use a DNS-aware ad blocker (uBlock Origin on Firefox, or Brave's built-in blocking), since a standard cookie- or domain-based blocklist can't see through a cloaked first-party-looking subdomain.
• Against local-storage evercookies — clear "all site data," not just cookies, and periodically check what's actually stored via your browser's developer tools.
• Against network-injected identifiers — a VPN encrypts your traffic before it reaches your carrier or network operator, closing the one gap none of the browser-side defenses above can touch.