What is fingerprint resistance — defending against browser and device identity tracking

The short version: a cookie is a piece of data the website stores on your device to recognize you next visit. A fingerprint is something completely different — it's a set of measurements the website takes about your device, combined into a string that's statistically unique. Cookies you can delete; fingerprints you can't, because they're properties of your hardware and software that the website just observes. A typical device fingerprint combines around 30 signals — screen resolution, installed fonts, GPU model, audio processing stack, language, timezone, browser version, and many subtler details — into a value that uniquely identifies maybe 1 in 10,000 to 1 in a million devices. Fingerprint resistance is the practice of making your device look like millions of other devices, so the fingerprint isn't unique enough to identify you. It's hard, it's imperfect, and the honest assessment is that perfect resistance probably isn't achievable on a modern browser — but meaningful resistance is, and the difference matters.

What a browser/device fingerprint actually is

When you visit a website, the page can run JavaScript that interrogates your browser and device for dozens of pieces of information. Some of this is necessary for the site to work — your screen size determines layout, your timezone determines how dates are displayed, your language preference determines which translation to load. The information is genuinely useful for the site. But it's also genuinely revealing: every piece of information narrows down which device the visitor is using, and enough pieces combined become unique.

The roughly 30 signals that go into a typical fingerprint include:

• User agent string — browser name and version, operating system, often the device model.
• Screen resolution and color depth — usually narrows down the device class.
• Timezone and language — narrows down geographic region and locale.
• Installed fonts — the set of fonts your OS has installed is surprisingly distinctive. A page can list them by trying to render text in each font and measuring whether the result looks like the font was present.
• Canvas fingerprint — the page draws a small image using HTML5 canvas, then reads back the pixel values. Different GPUs, fonts, and rendering libraries produce slightly different pixels, even from identical drawing commands. The resulting hash is extremely identifying.
• WebGL fingerprint — similar idea but using WebGL graphics commands. Reveals the GPU model, driver version, and rendering quirks.
• Audio fingerprint — the page generates a brief audio signal and reads back what the audio processing stack produces. Different sound cards, OS audio APIs, and audio driver versions produce different output.
• Hardware concurrency — number of CPU cores. Reveals device class.
• Device memory — RAM size, exposed via the navigator.deviceMemory API.
• Battery API — battery level, charging state, charging time. Largely deprecated by browsers due to fingerprinting concerns, but historically used.
• Touchscreen capabilities — number of touch points supported, distinguishing tablets from laptops.
• Media devices — number of cameras, microphones, speakers attached.
• Plugins list — browser plugins/extensions visible via the DOM (less useful in modern browsers but still leaked in places).
• CSS media queries — the page queries dozens of media features (prefers-color-scheme, prefers-reduced-motion, color-gamut, etc.) and records the answers.
• TLS fingerprint (JA3/JA4) — network-layer signal: the order and content of fields in your TLS Client Hello packet identifies the TLS library, sometimes more uniquely than user agent.
• HTTP/2 fingerprint (Akamai H2) — at the HTTP/2 protocol layer, frame ordering and settings reveal the HTTP client library.
• Behavioral signals — typing rhythm, mouse movement patterns, scroll velocity, the way you tab between fields. Distinctive over even short interactions.

None of these signals is individually identifying. Many devices have the same screen resolution, many have the same browser version, many have the same fonts installed. But the combination of all 30 — the specific tuple of values — is usually unique. The EFF's Panopticlick research (now called Cover Your Tracks) showed that a typical browser's fingerprint is unique among hundreds of thousands of visitors with high probability.

Why fingerprinting survives cookie clearing and incognito mode

Cookie-based tracking depends on the browser cooperating: the browser stores the cookie, sends it on subsequent requests, and the website reads it. If you delete the cookie or block it, the tracking link breaks. Fingerprint-based tracking depends on the browser revealing information about itself and its environment when asked — and that information doesn't change just because you cleared storage.

Concretely: you delete all cookies, open an incognito window, connect to a VPN, and visit a tracking-heavy site. The site's JavaScript runs the fingerprint collection routine, gets the same 30 signals it would have gotten otherwise, computes the same fingerprint hash, and recognizes you. Your IP address is different (you're on a VPN). Your cookie is empty (incognito doesn't share). But your screen is the same screen, your GPU is the same GPU, your installed fonts are the same fonts, your timezone is still America/New_York. The fingerprint identifies the device, not the session.

This is why ad-tech companies and analytics platforms invested heavily in fingerprinting starting around 2014, well before third-party cookies started being phased out by browsers. They wanted a tracking mechanism that survived the privacy controls users were starting to use. They got one.

The three main fingerprint sources

Fingerprint signals come from three different layers of the stack. They have different mitigations, and a defense that addresses one layer may leave the others fully exposed.

1. HTTP headers (basic, lowest-resolution layer)

Every HTTP request includes headers like User-Agent, Accept-Language, Accept-Encoding, and Sec-CH-UA-* (the newer Client Hints). These reveal browser, OS, language, and encoding preferences. The header set is low-bandwidth — maybe a dozen bits of entropy — but it narrows the universe of possible devices significantly. Defenses at this layer (spoofing the user agent, harmonizing language preferences) are cheap and partially effective, but they don't address the much higher-bandwidth signals from the JavaScript layer.

2. JavaScript APIs (the largest fingerprint surface)

The browser exposes dozens of JavaScript APIs that fingerprinting scripts query — navigator.userAgent, screen.width, navigator.languages, Intl.DateTimeFormat().resolvedOptions().timeZone, the WebGL extensions list, the audio context's processing characteristics. Canvas fingerprinting via HTMLCanvasElement.toDataURL() alone is responsible for a huge portion of the entropy in a typical fingerprint. WebGL adds more. The Web Audio API adds more. This is where most of the fingerprint bits come from, and it's the hardest layer to defend at because the APIs are genuinely useful for legitimate web applications.

3. TLS and network layer (advanced)

Before any HTTP request, your browser performs a TLS handshake. The Client Hello message — the first packet the browser sends — contains the list of supported cipher suites, the supported TLS extensions, the order of those extensions, and various other parameters. The combination is the TLS fingerprint, captured by tools like JA3 and JA4. Different TLS libraries (the Chrome bundled version, Firefox's, Apple's CoreTLS, Go's crypto/tls, Python's requests) produce different fingerprints. A network observer who knows what TLS fingerprint your browser normally produces can identify you even if you change browsers but use the same OS, or recognize when an automated tool (curl, requests, scrapers) is impersonating a browser unsuccessfully. The HTTP/2 frame ordering and SETTINGS values produce a similar but separate fingerprint. These layers are largely outside what the user can control — they're functions of the underlying TLS library — and they're invisible to defenses that operate inside the browser.

What "uniqueness" actually means — EFF's Cover Your Tracks methodology

The EFF maintains a tool at coveryourtracks.eff.org that tests your browser against a real-world fingerprinting setup and tells you how unique your fingerprint is. The methodology is informative regardless of whether you run the test yourself.

The tool computes an "entropy" measurement: how many bits of identifying information your fingerprint contains. The math is straightforward — if your fingerprint matches 1 in 10,000 visitors, that's about 13.3 bits of entropy (log2(10000)). If it matches 1 in 1 million, that's about 20 bits. The tool also shows which specific signals contribute the most entropy in your case — for example, your canvas fingerprint might be 12 bits unique, your fonts list 8 bits, your screen resolution 4 bits, your timezone 6 bits. The total is the sum (assuming the signals are independent, which they aren't quite, but it's a useful approximation).

For perspective: 13 bits of entropy means the fingerprint plus your IP address geolocation is essentially unique. 20 bits means it's unique among everyone on the planet. The threshold for "anonymized" data under most privacy frameworks is somewhere around 10 bits — below that, you have plausible deniability. Above 20 bits, you're individually identifiable. Most browsers running default settings produce fingerprints in the 18-22 bit range.

Fingerprint signal map

Here's where the major fingerprint signals come from, whether clearing cookies removes them (they don't), whether a VPN protects against them (mostly doesn't), and whether defending requires browser-level hardening (mostly yes):

The pattern is consistent. Almost everything that contributes to your fingerprint survives both cookie clearing and VPN use. Cookies and IP address are just two of the 30+ signals; addressing only those two changes nothing about the rest.

How browsers attempt fingerprint resistance

Tor Browser — the gold standard

Tor Browser is the most aggressive consumer browser for fingerprint resistance. It deliberately makes every Tor Browser user look identical: same default window size (the browser opens at 1000x1000 and resists resizing, then it letterboxes content if you maximize), same set of fonts visible to JavaScript, same canvas behavior (all canvas reads return whitelisted-only or prompt the user), same WebGL behavior (largely disabled), same timezone (always UTC). The trade-off is severe — many websites break, performance suffers from the Tor network, and the user experience is constrained. But fingerprint resistance is dramatically better than any other browser. The fingerprint a website sees from Tor Browser is approximately the same fingerprint it sees from every other Tor Browser user, which is the only known approach to actually anonymizing the fingerprint signal at scale.

Brave — strategic randomization

Brave takes a different approach. Rather than making all users look identical (the Tor strategy), Brave makes the same user look slightly different on each visit. Canvas readings include per-session noise, font enumeration is randomized, audio context is fuzzed. The strategy is called "randomization" or sometimes "per-session shielding." It doesn't reduce uniqueness within a single visit, but it prevents long-term tracking by making the fingerprint unstable across visits. The trade-off is that some sites with strong anti-fraud detection (banking, betting) may flag the inconsistency as suspicious.

Firefox resistFingerprinting

Firefox has a hidden preference, privacy.resistFingerprinting, that enables a suite of Tor-Browser-derived defenses: a fixed window size, a fixed timezone (UTC), restricted font visibility, canvas read prompting, and several other measures. The Mozilla documentation for the feature describes the full set of behaviors. It's the closest you can get to Tor Browser's fingerprint behavior without the Tor network itself, and it works in a standard Firefox install. The compatibility trade-offs are significant — many sites break visually, some break functionally — which is why it's not on by default.

Safari ITP and beyond

Safari's Intelligent Tracking Prevention (ITP) addresses some fingerprinting vectors but focuses primarily on cross-site tracking via storage. Safari 14+ added font enumeration limits and a few other fingerprint surface reductions. Safari 17 added Advanced Tracking and Fingerprinting Protection, which actively blocks known fingerprinting scripts identified by Apple's Privacy team. The approach is conservative — Apple values site compatibility heavily — but it's getting more aggressive with each release.

What network-level defenses can and cannot do

A VPN, a privacy-focused DNS resolver, and tracker filtering at the network layer collectively address part of the privacy problem — but specifically not the fingerprinting part. Worth being honest about what each layer addresses:

• VPN hides your IP address — useful for hiding your geolocation from the destination site and for hiding which sites you visit from your ISP. Does not affect any of the JavaScript-layer fingerprint signals. The site still sees your canvas, fonts, GPU, timezone — just from a different IP.
• DNS-level filtering blocks known fingerprinting scripts — at the network layer, you can block requests to known fingerprinting domains (like fingerprintjs.com or various ad-tech endpoints that bundle fingerprinting). This is partial but real: it stops the most prevalent fingerprinters from running at all. Sites that bundle fingerprinting code into their own first-party domain are not blocked by this approach. We cover the DNS-filtering mechanism in our writeup on how to stop online tracking.
• Tracker filtering — similar to DNS filtering but operates on URLs rather than domains. Effective against fingerprinters that load from distinctive paths even on shared CDN domains. See our tracker filtering feature.
• Decoy traffic — addresses traffic-analysis style threats but not fingerprinting. The two threat models are distinct. We have a separate writeup on decoy networks.

The honest framing: network-level defenses reduce how much fingerprinting happens by blocking many of the scripts that would do it. They don't reduce how identifying your fingerprint is when fingerprinting does happen — that's a browser-level concern.

The honest current state — perfect resistance is hard

A few uncomfortable truths about fingerprint resistance, worth saying explicitly:

Perfect resistance probably isn't possible without breaking the web. The web platform genuinely needs access to many of the signals that fingerprinting exploits. Layout needs screen size. Internationalization needs language and timezone. Adaptive content needs device capabilities. The signals fingerprinting uses are not artifacts — they're real properties the platform exposes for legitimate reasons. Eliminating them entirely would break too much.

Resistance that "looks unique" is worse than no resistance. If you customize your browser heavily with extensions, custom fonts, custom settings, you become more unique than a default user, not less. The Tor Browser strategy works because every Tor Browser user looks identical; the strategy of installing 12 privacy extensions on a custom browser configuration produces a fingerprint that's more identifying than the original.

The arms race continues. Browser-level defenses get added; fingerprinting scripts find new signals to exploit. New APIs (battery, gamepad, WebGPU, device orientation) introduce new fingerprint surface. Mitigations age into ineffectiveness. The state of the art changes every year or so. Anything described in this article was true at the time of writing but may need revision in 18 months.

Anti-fraud systems use fingerprinting too. When you log into your bank, the bank fingerprints your device to detect account takeover ("this login is from a device we've never seen before"). Aggressive fingerprint resistance can flag your sessions as suspicious. The tools that defend against tracking also defeat anti-fraud detection — that's a real trade-off, not a side effect, and it's worth considering for your specific risk profile.

Practical resistance levels for different threat models

The right level of fingerprint resistance depends on what you're trying to defend against. A handful of common scenarios:

Casual privacy ("I don't want ad-tech profiling me")

A standard browser (Safari, Firefox, Brave) with the default tracking-protection settings on, plus network-level tracker filtering. This blocks the bulk of off-the-shelf fingerprinting scripts (which load from known third-party domains) and limits cross-site tracking via storage. Your fingerprint is still individually identifying if a site bothers to compute it, but most sites don't bother — the cost-benefit doesn't justify it for non-revenue-critical sites. The default privacy posture handles 80% of the threat with effectively zero usability cost.

Surveillance-resistant ("I'm a journalist, activist, or researcher")

Tor Browser for the activities you want anonymous. A separate standard browser for everything else. Avoid mixing identities between the two browsers. Recognize that even within Tor Browser, behavioral fingerprinting (typing rhythm, browsing patterns) can still identify you to a sufficiently motivated adversary. The Tor Project's own documentation is the right place for the specifics of this threat model. Network-level defenses help but the browser is the primary defensive surface.

State-level adversary

Honest assessment: against a nation-state adversary with the resources to combine network observation, device fingerprinting, behavioral analysis, and traditional intelligence work, browser-level fingerprint resistance is one input among many. Tor Browser is still useful (it raises the cost), but operational security practices (compartmentalized devices, disciplined identity separation, OPSEC training) matter more than any single browser configuration. This is the threat model the Tor Project explicitly designs for; consumer privacy tooling is not built for it.

For most readers — the first two threat models — the practical advice is: use a modern privacy-respecting browser (Brave, Firefox with reasonable settings, or Safari), enable its built-in tracking protection, layer network-level filtering on top, and recognize that fingerprinting is a real residual risk that no consumer tool fully addresses. The combination is meaningfully better than the default — without it, you're individually identifiable across every site you visit; with it, you're identifiable mainly to sites that specifically invest in fingerprinting and are willing to spend the engineering effort.

Casper's Cloak addresses the network-layer slice of this defensive stack. Our tracker filtering blocks known fingerprinting endpoints at the DNS layer, alongside the broader ad-tech and analytics ecosystem. The VPN tunnel hides your IP and prevents your ISP from observing which sites you visit. Neither addresses browser-level fingerprint surface — for that, choose your browser carefully and consider Tor Browser when the threat model warrants it. The combination of well-chosen browser + network-level filtering is the realistic best-effort posture for most users, and it's substantially better than the default.

For the canonical reference and a quick personal entropy measurement, run EFF's Cover Your Tracks tool in whichever browser you actually use. The result will tell you, in concrete bits of entropy, how identifying your current setup is. From there, the trade-off between privacy and usability becomes a quantitative decision instead of a vague gesture toward "more privacy."

Bottom line: fingerprint resistance is real, it's imperfect, and the right posture depends on your threat model. The honest answer to "how do I prevent fingerprinting?" is "you can't fully — but you can substantially reduce who can do it, what they see, and how stable the identifier is across visits."