How Websites Track You Without Cookies (and What to Do)

Clear your cookies, open a private window, and load a site you visit often. There's a decent chance it still knows exactly who you are.

That surprises people, because for two decades the entire privacy conversation revolved around one small text file. Delete the cookie, the story went, and you become a stranger again. The advertising industry heard that story too — and spent those same two decades building identification systems that don't need cookies at all. Some of them run in JavaScript. Some run at the network layer, before your browser has rendered a single pixel. Some never touch your device: they live in server logs and identity databases you'll never see.

This article is a technical walkthrough of how websites track you without cookies — every major technique in use today, roughly ordered from most common to most exotic — followed by an honest assessment of which defenses work, which backfire, and why the answer for people managing multiple online identities looks different from the answer for everyone else.

Why cookie-blocking stopped being enough

A quick bit of history, because it explains everything that follows.

Safari started aggressively restricting third-party cookies with Intelligent Tracking Prevention in 2017. Firefox followed with Enhanced Tracking Protection in 2019. Chrome — the browser with the most to lose, given who makes it — spent years announcing, delaying, and re-scoping its own third-party cookie phase-out. The direction of travel was obvious to every ad-tech engineer by 2018 at the latest.

So they adapted early. By the time browsers actually shipped their restrictions, the tracking industry had already migrated its identification workload to techniques that don't depend on the browser politely storing and returning an ID. The cookie didn't die so much as get demoted: it's now one signal among a dozen, and rarely the most important one.

Here's the uncomfortable framing that makes the rest of this article click: a cookie is an identifier your browser volunteers. Everything below is an identifier your browser leaks. You can refuse to volunteer information. Leaks are much harder to plug, because they're side effects of how the web platform fundamentally works.

Browser fingerprinting: the workhorse of cookieless tracking

If you only learn one technique from this piece, make it this one. Browser fingerprinting is the dominant answer to how websites track you without cookies, and it's the foundation nearly every commercial anti-fraud and cross-site tracking product is built on.

The idea is simple. Your browser answers hundreds of questions about itself — screen size, installed fonts, GPU model, timezone, language list, audio hardware behavior. No single answer identifies you. But the combination is so specific that, in the EFF's original Panopticlick research and its successor project Cover Your Tracks, the large majority of tested browsers turned out to be unique or nearly unique. You only need about 33 bits of entropy to distinguish one person among eight billion. A typical desktop browser gives away considerably more than that without a single permission prompt.

What a fingerprint is actually made of

The cheap signals come straight off the navigator and screen objects: user agent string, platform, language list (en-US,en,de is rarer than you'd think), timezone, screen resolution and color depth, device pixel ratio, hardwareConcurrency (your CPU core count), deviceMemory, touch support, and the list of supported media codecs. Each one is a few bits of entropy. None requires anything more than one line of JavaScript.

What makes fingerprinting powerful is internal correlation. A tracker doesn't just record that you claim to run Windows — it checks whether your fonts, your GPU strings, your codec support, and your scrollbar rendering agree that you run Windows. That cross-checking is exactly what defeats naive spoofing, and we'll come back to it, because it's the single most misunderstood point in this whole field.

Canvas and WebGL: your GPU has an accent

Canvas fingerprinting deserves its own explanation because it's clever in a way that surprises even developers. A script uses the Canvas API to draw a hidden test image — usually a string of text in several fonts, some overlapping shapes, an emoji or two — then reads the pixels back and hashes them. You never see anything. The whole operation takes a few milliseconds.

Why does that identify anyone? Because the exact pixels produced depend on your GPU model, your graphics driver version, your operating system's font rasterizer, its anti-aliasing and subpixel-hinting settings, and the browser's rendering pipeline. Two machines drawing the same text produce subtly different pixels — a red channel off by one here, a smoothed edge there. The hash of those differences is stable for your machine and different from your neighbor's.

WebGL extends the same trick into 3D and adds something even blunter: the API will simply tell a website your graphics hardware. The unmasked renderer string looks like ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0) — actual GPU model, actual graphics backend, sitting right there in a JavaScript-readable string. Combine the renderer string with a rendered-scene hash and a list of supported WebGL extensions and precision formats, and the GPU alone often narrows you to a handful of machine configurations. WebGPU, the newer API, exposes its own set of adapter details and limits that fingerprinting scripts have already started harvesting.

Audio fingerprinting

Same concept, different hardware path. A script builds a silent audio graph with the Web Audio API — an oscillator feeding a compressor, typically — renders it offline, and reads back the resulting waveform samples. Floating-point audio processing differs minutely across CPU architectures, browser builds, and OS audio stacks, so the output samples hash to a value that's consistent on your machine and distinct across the population. No sound plays. No permission is requested. It's a couple of entropy bits that cost the tracker nothing.

Fonts and rendering quirks

Your installed font list is a biography. Adobe apps install fonts. Microsoft Office installs fonts. That obscure design tool you tried in 2023 installed fonts. Trackers enumerate them without any font-listing API by measuring text: render a test string in a fallback font, record its width, then request it in 500 candidate fonts and see which ones change the measurement. Present fonts alter the metrics; absent ones fall back. A corporate laptop, a designer's Mac, and a gamer's PC produce wildly different lists, and those lists barely change over time — which makes fonts one of the stickiest signals in the whole fingerprint.

User-Agent Client Hints: the replacement leaks too

Browser vendors knew the user agent string was an entropy disaster, so Chromium froze most of it and introduced User-Agent Client Hints — a structured mechanism where sites explicitly request details like full browser version, OS version, architecture, bitness, and device model. The privacy improvement is real but partial: the data is now gated behind a request instead of broadcast to everyone. The catch is that any site that wants those high-entropy values can simply ask for them, and mainstream browsers will answer. For tracking purposes, UA-CH mostly reshuffled where the information lives. It also created a new consistency trap: if your user agent claims one thing and your client hints claim another, you've just raised a fraud flag no honest browser ever raises.

Network-level identifiers: tracking before JavaScript runs

Everything above requires running code in your browser. This next category doesn't, which is why script blockers can't touch it.

Your IP address is the oldest tracker there is

It's unfashionable to mention because it's boring, but the IP address remains a first-class identifier. A residential IP often maps to one household for weeks. Even behind carrier-grade NAT, the combination of IP plus a coarse fingerprint separates the users sharing it. Trackers also derive geography, ISP, and — critically — IP reputation from it: datacenter ranges, known VPN exits, and proxy pools are all catalogued, and being on a flagged range is itself a signal that changes how sites treat you.

This is also where a common misconception lives: that a VPN solves tracking. It changes exactly one signal — the IP — while your fingerprint stays identical, which means any site that saw you before the VPN can trivially match you after it. We've written a full breakdown of that gap in what actually separates an antidetect browser from a VPN, and the short version is: they solve different layers of the same problem, and neither substitutes for the other.

TLS and TCP fingerprints

Before your browser sends a single HTTP request, it performs a TLS handshake — and the handshake itself is a signature. The list of cipher suites your client offers, their order, the extensions it includes, the elliptic curves it supports: that combination, hashed into what the industry calls a JA3 or JA4 fingerprint, reliably distinguishes Chrome from Firefox from Safari from curl from a Python script pretending to be Chrome. Anti-bot vendors lean on this heavily because it's nearly impossible to fake from a high-level HTTP library. One layer down, TCP characteristics like initial window size and TTL hint at your operating system. If your HTTP headers say Windows Chrome but your TLS handshake says OpenSSL-on-Linux, no cookie policy in the world will save you from being flagged. This is a huge part of why scraping operations get blocked even with perfect headers and rotating proxies.

Storage tricks that outlive cookie clearing

Cookies are just the most famous place a browser stores state. Trackers have abused nearly every other one.

ETags and cache-based supercookies

The ETag is an HTTP caching header with a legitimate job: the server tags a resource with a version identifier, your browser stores it, and sends it back on the next visit so the server can reply "nothing changed." The abuse is elegant and nasty. Instead of a version identifier, the server hands each new visitor a unique ETag on some tiny resource — a one-pixel image, say. Your browser dutifully caches it and presents it on every return visit. Congratulations: you're carrying a persistent identifier that survives cookie clearing entirely, because it lives in the HTTP cache, not the cookie jar. Modern browsers have blunted this by partitioning caches per site, but the technique still works within a site's own domain and on browsers with weaker partitioning.

localStorage, IndexedDB, and service workers

The web platform offers several storage APIs bigger and longer-lived than cookies: localStorage, IndexedDB, the Cache API, service worker registrations. Every one of them can hold a copied identifier. The classic "evercookie" demonstration wrote the same ID to a dozen storage locations simultaneously and resurrected it from any survivor when you cleared the others. Browsers now clear these alongside cookies when you wipe site data — but only if you actually wipe all site data, which the average "clear cookies" reflex doesn't do.

HSTS supercookies and favicon caches

Two exotic ones worth knowing because they illustrate how deep this goes. HSTS — the mechanism that tells browsers "always use HTTPS for this domain" — can be turned into a bit store: a tracker sets HSTS on a unique subset of 20-odd controlled subdomains, then later probes which ones your browser auto-upgrades to HTTPS, reading back a 20-bit identifier from pure security state. Favicon caches got the same treatment in a 2021 research paper: the favicon cache persisted even in private windows on some browsers, allowing an ID to be encoded in which favicons you'd cached. Both are mostly patched in current browsers. Both worked for years first. The lesson isn't these specific tricks — it's that any state a browser keeps between visits, however innocent, is a candidate identifier.

Tracking that never touches your browser

The most durable tracking of all happens where no browser setting can reach it.

Server-side tagging and CNAME cloaking

Content blockers work by recognizing tracker domains and refusing to load them. So trackers stopped using recognizable domains. With CNAME cloaking, a site points a subdomain of itself — metrics.trustednewspaper.com — at a third-party tracking service via DNS. Your browser sees a first-party subdomain, extends it first-party trust (including first-party cookies, ironically), and most blockers wave it through. Server-side tagging goes further: the website's own server collects your behavior and forwards it to analytics and ad platforms entirely backend-to-backend. From your browser's perspective, you only ever talked to the site you visited. There is no client-side defense against server-side forwarding, full stop. That data flow happens on machines you don't control.

Identity graphs, hashed emails, and login walls

Step back from the mechanics and look at the business layer. When you log in anywhere, or type an email into a newsletter box, that email — usually hashed — becomes a durable identifier that identity vendors match across every other site where the same email appeared. These "identity graphs" stitch together your devices, browsers, and even offline purchase data into one profile keyed on stable real-world identifiers. This is why the industry's answer to cookie deprecation was a wave of login walls: a logged-in user needs no cookie tricks at all. It's also why platforms like Facebook and Google are largely indifferent to cookie death — their users are authenticated, which is the strongest identifier there is.

URL decoration: gclid, fbclid, and friends

Ever noticed ?fbclid=... or ?gclid=... trailing links you click from apps and ads? Those are click identifiers generated per-click and passed through the URL itself. The destination site reads the parameter, associates it with everything you do there, and reports back — reconnecting your ad click to your on-site behavior with no third-party cookie involved. Link decoration is trivially effective because URLs are the one channel no privacy setting can sanitize without breaking navigation itself, though Safari and Firefox now strip the best-known parameters in some modes.

Behavioral signals: you are how you type

One more layer, and it's the eeriest. Behavioral biometrics products profile how you use your device: typing cadence and inter-key timing, mouse acceleration curves, how you hesitate before clicking, scroll rhythm, whether you tab between form fields or click them. These signatures are surprisingly stable per person and are used both to recognize returning users and — more commonly — to separate humans from automation, since scripted input has telltale uniformity that human motor control never does. If you've ever wondered how a bank spots a fraudster who has the correct password, or how an anti-bot system flags a scraper that got every fingerprint right, behavior is usually the answer.

Cookieless tracking at a glance

Read the columns and the pattern jumps out: the tools most people reach for — clearing cookies, going incognito, switching on a VPN — each defeat almost nothing on this list on their own. Effective defense has to be layered, and it has to match the technique.

What actually works against cookieless tracking

Enough diagnosis. Here's the practitioner's view of defense, including the part most privacy articles get wrong.

Step one: know your exposure

Spend five minutes on Cover Your Tracks and look at the bits-of-entropy figures next to each signal, not just the headline verdict. Then check what your browser leaks at the network level. Most people discover their "private" setup is unique among hundreds of thousands of tested browsers. You can't reason about defenses until you've seen your own numbers.

Step two: understand the entropy paradox before you spoof anything

Here's the counterintuitive core of fingerprint defense. Your instinct says: lie about everything. Install an extension that randomizes your canvas hash, fake your user agent, spoof your timezone. The result, almost always, is that you become more identifiable, not less — because trackers don't just read values, they cross-check them. A user agent claiming Windows paired with macOS font metrics is a contradiction no real machine produces. A canvas hash that changes on every page load is a flag in itself, because real hardware is boringly consistent. Detection systems explicitly score these contradictions; an impossible configuration is a louder signal than a common one.

The two coherent strategies are the ones Wikipedia's overview of device fingerprinting hints at and practitioners live by. Blend in: use a browser like Tor Browser or hardened Firefox that makes many users look identical, accepting the breakage that uniformity costs. Or present a different-but-internally-consistent identity: look like a specific, plausible, real machine — coherent from the GPU strings down to the font list — that simply isn't your machine. The first strategy suits anonymous browsing. The second is the only one that works when you need to be a stable, credible, returning "person" — which brings us to the multi-account problem.

Step three: if you run multiple identities, isolation beats hiding

For a big group of readers — agencies running client ad accounts, e-commerce sellers with multiple storefronts, ad-arbitrage teams, researchers — the goal was never to be invisible. It's the opposite: each account should look like a distinct, consistent, unremarkable user, and nothing should ever connect them. Every technique in this article is a thread that can tie account B to banned account A: shared fingerprint, shared IP, shared cache state, shared localStorage, shared behavioral session.

That's the specific problem antidetect browsers exist to solve, and it's worth being precise about the mechanism (we cover it in depth in what an antidetect browser is and how it works). Dual Login's approach: every profile is a separate real browser process with its own data directory — so cookies, cache, ETags, localStorage, IndexedDB, and service workers are physically separate files, and cache-based supercookies can't cross profiles even in principle. Each profile carries its own generated fingerprint — canvas, WebGL, audio, fonts, screen, timezone, languages — applied natively inside the browser engine rather than by injected JavaScript, which matters because injected spoofing is itself detectable and often misses contexts like web workers. And each profile can route through its own proxy, with WebRTC masked to the proxy's exit IP so the network story matches the fingerprint story.

Internal consistency is the whole game. A profile that claims a specific GPU renders like that GPU. A profile exited through a German residential IP speaks German timezone and locale. Nothing contradicts, so nothing flags. If you're evaluating this class of tool, our guides to managing accounts at scale and profile management practices for teams cover the operational side — naming, proxy hygiene, who touches which profile — which in practice determines success as much as the technology does.

Where this is heading

Two currents are worth watching. First, browsers keep tightening the platform: storage partitioning is now standard, Chrome's Privacy Sandbox replaced individual-level ad targeting with the cohort-style Topics API and on-device attribution, and fingerprinting surface gets trimmed release by release. Second — and pulling the opposite direction — tracking keeps migrating to layers browsers can't govern: server-side pipelines, login-keyed identity graphs, TLS-level classification, and machine-learning models that re-identify users probabilistically from whatever signals remain. The realistic forecast isn't that tracking dies; it's that it becomes less visible and more concentrated in the platforms that own authenticated audiences. Which makes the practical skills — knowing your exposure, keeping identities consistent, isolating what should never touch — more valuable over time, not less.

FAQ

Can websites track me in incognito mode?

Yes, within the session and often across sessions. Incognito gives you a fresh cookie jar and cache that are discarded on close — nothing more. Your fingerprint is identical to your normal window's, your IP is unchanged, and your TLS signature is the same, so fingerprinting-based tracking works in incognito exactly as well as anywhere else. It protects your local history from other people using your device, not your identity from websites.

Does a VPN stop browser fingerprinting?

No. A VPN replaces one signal — your IP address — and leaves every fingerprinting signal untouched. A site that fingerprinted you before you connected will recognize you after. VPNs and fingerprint management address different layers; serious setups use both, with the IP and the fingerprint kept consistent per identity.

Is browser fingerprinting legal?

Broadly, it operates in a grey zone that regulators are narrowing. In the EU, guidance under GDPR and the ePrivacy rules treats fingerprinting for tracking like cookies — requiring consent — but enforcement has lagged, and fingerprinting for fraud prevention is generally treated more permissively. In most other jurisdictions it's essentially unregulated. Practically: assume it's happening on any commercial site, consented or not.

How unique is my browser fingerprint?

Almost certainly unique or close to it. Distinguishing one person among eight billion requires about 33 bits of entropy, and studies from Panopticlick onward consistently find that a typical desktop browser exposes more than that through fonts, canvas, WebGL, and configuration details alone. Mobile browsers are somewhat less unique because the hardware and software are more standardized.

Does clearing cookies still do anything?

It's worth doing, but it addresses only the most polite tracking. Fingerprinting, IP tracking, TLS signatures, server-side pipelines, and login-based identity all survive it, and cache-based identifiers survive unless you clear all site data rather than cookies alone. Think of it as hygiene, not protection.

Can I just disable JavaScript to stop fingerprinting?

It blocks canvas, WebGL, audio, and font probing — and breaks most of the modern web. It also does nothing about IP tracking, TLS fingerprinting, ETag supercookies, or server-side tracking, and running with JavaScript disabled is itself a rare, conspicuous trait. For most people it costs far more than it protects.

The bottom line

Cookies were never the tracking mechanism — they were just the visible one. The durable answer to how websites track you without cookies is: through everything your browser is rather than anything it stores. Your hardware's rendering accent, your network's handshake, your login identity, your typing rhythm. Defenses that address one layer while ignoring the rest mostly produce false confidence.

If your concern is general privacy, harden a mainstream browser and accept the trade-offs. If your work depends on running multiple accounts that must never be linked — for clients, stores, or research — you need isolation and per-identity consistency, not hiding. That's exactly what Dual Login was built for: real, separate browser processes with natively consistent fingerprints, isolated storage, and per-profile proxies. See what to test during a trial and put your own setup through the fingerprint checkers before and after — the numbers make the argument better than we can.