For 25 years, tracking users across the web meant cookies. Drop one, read it later, follow the user. Modern browsers and privacy regulations have eroded the cookie model. The new tracking foundation is browser fingerprinting — identifying users by the characteristics of their browser instead of by an identifier you stored.

This post compares the two approaches, explains what’s changed, and discusses why fingerprinting is harder to defeat than cookies.

Cookies, Briefly

A cookie is a key-value pair the browser stores on behalf of a site. When you visit example.com, you might get:

Set-Cookie: user_id=12345; Domain=example.com; Path=/; HttpOnly; Secure; SameSite=Lax

On every subsequent request to example.com, the browser sends:

Cookie: user_id=12345

The site can identify you by the cookie’s value. Different sites have different cookies; users can clear them.

First-party vs third-party

First-party cookie — Set by the site you’re visiting.
Third-party cookie — Set by a different site embedded in the page (ad networks, trackers).

Third-party cookies enabled cross-site tracking: visit Site A with Ad Network X embedded → X sets cookie. Visit Site B with same X embedded → X reads cookie. X knows you visit both sites.

Why cookies are dying

Safari blocks third-party cookies by default (since 2020).
Firefox blocks by default (since 2019).
Chrome has been “phasing out” third-party cookies since 2020 — finally deprecated in 2024-2025 with various replacements.
GDPR / cookie consent banners require explicit user opt-in.

Result: third-party cookies are essentially gone for typical web tracking. First-party cookies still work but only let one site track within itself.

Browser Fingerprinting

The replacement: identify users by their browser’s characteristics, not by stored identifiers.

Signals available to JavaScript:

User-Agent — browser, OS, version.
Screen resolution — screen.width, screen.height.
Color depth — bits per pixel.
Timezone — Intl.DateTimeFormat().resolvedOptions().timeZone.
Language — navigator.language.
Fonts — list of installed fonts (detected by rendering tests).
Canvas fingerprint — render text to canvas; hash the resulting pixels. Subtle differences in rendering between machines produce different hashes.
WebGL fingerprint — render 3D scenes; hash output. GPU and driver dependent.
AudioContext fingerprint — synthesize audio; hash output. CPU and audio stack dependent.
Plugins — enumerable plugin list (mostly empty in modern browsers).
Hardware concurrency — navigator.hardwareConcurrency (CPU cores).
Touch capability — 'ontouchstart' in window.
Connection type — navigator.connection.effectiveType.

Combine these and you get a fingerprint that’s surprisingly unique. Even without a user identifier, the same browser is likely the same user across visits.

Information Theory of Fingerprinting

The math: each signal carries some entropy (information about the user). Combining signals adds entropy.

User-Agent: maybe 5 bits (many users share it).
Screen resolution: 5-7 bits.
Canvas fingerprint: 10-15 bits.
Fonts list: 10-20 bits.
…

Sum: 30-50+ bits of entropy. With more than 30 bits, you can uniquely identify users in a population of a billion.

Panopticlick (now AmIUnique.org) demonstrated this in 2010 with desktop browsers. Mobile has lower variance (fewer screen sizes, more standardized hardware), but still 25-35 bits.

Why Fingerprinting Is Harder to Defeat

Cookies can be cleared with one click. Fingerprinting can’t — your browser’s characteristics are inherent.

Mitigations:

Tor Browser

Deliberately homogenizes fingerprint. Every Tor user reports the same screen size, same User-Agent, etc. Less entropy = less distinguishable.

Brave

Adds noise to canvas fingerprints and other signals. Each session looks slightly different.

Firefox enhanced tracking protection

Blocks scripts known to fingerprint.

Safari

Restricts some signals (font enumeration, etc.).

But the user’s IP address, screen resolution, time zone, and language don’t disappear. They’re real characteristics that vary across users.

Server-Side Fingerprinting

Beyond JavaScript-driven fingerprinting, server-side signals contribute:

IP address — Geolocation, ASN, network type. See Ip2Geo.
TLS fingerprint (JA3/JA4) — Cipher list order, TLS version, extensions.
TCP fingerprint — OS-specific TCP behavior. See passive OS fingerprinting.
HTTP/2 fingerprint — Stream priorities, headers order.
HTTP headers — Accept-Language, Accept-Encoding order, Sec-CH-UA.

A server can collect a fingerprint without any cooperation from JavaScript.

Where Fingerprinting Is Legitimate

Despite its tracking implications, fingerprinting has legitimate uses:

Fraud detection

“Same fingerprint, different user account — possibly the same attacker.” This is a major use case in financial services and account-takeover prevention.

For more, see bot detection strategies.

Bot detection

Browser bots (Puppeteer, Playwright) have subtle fingerprint differences from real browsers. Detection products use fingerprinting to identify them.

Account-takeover prevention

“Logging in from a never-before-seen fingerprint — challenge the user.”

Anti-abuse

“This fingerprint is associated with confirmed fraud — block.”

Audit / compliance

“Confirm this transaction came from the device that logged in.”

The line between “tracking” and “security” is blurry. The same fingerprint used for advertising would be tracking; used for account security, defense.

Regulatory Status

Under GDPR, fingerprinting is personal data — it identifies the user even without an explicit identifier. The same consent requirements apply.

Some jurisdictions specifically regulate fingerprinting:

EU ePrivacy Directive requires consent.
California’s CCPA treats fingerprints as personal info.
Various other states / countries have similar provisions.

For application developers using fingerprinting: disclose in privacy policy; obtain consent where required; respect “do not track” signals where they exist.

Mitigations and Counter-Mitigations

A constant arms race:

Browsers limit signals

Firefox blocks canvas fingerprinting from low-reputation scripts. Safari restricts font enumeration.

Fingerprinters use harder-to-block signals

Move from canvas to AudioContext. Move from JS-accessible to server-side TLS fingerprinting.

Privacy-focused users use Tor or randomization

Reduces fingerprint entropy.

Bot networks copy real users’ fingerprints

“Browser leak” databases sell fingerprints from real browsers; bots can replay them.

The arms race continues. In 2026, sophisticated fingerprinting + sophisticated counter-measures coexist; neither side has won.

Building Fingerprinting Into Your App

If you implement fingerprinting for fraud/abuse detection:

Use libraries

FingerprintJS, ClientJS, or commercial APIs (FingerprintJS Pro, IPQS Device Fingerprinting). Don’t roll your own.

Combine with server-side signals

TLS / TCP fingerprint
IP / ASN classification
Behavioral signals

Have an override path

Real users will sometimes get false-positives. Give them a way to verify (email, SMS) and override.

Be transparent

Limit retention

Like with IP anonymization, don’t keep raw fingerprints forever.

When Cookies Still Beat Fingerprinting

For first-party use cases:

User sessions

A logged-in user has a cookie. You don’t need to fingerprint; you have a real identifier.

A/B test variant assignment

First-party cookies for the duration of the test.

Authentication

JWT or session cookies. See JSON Web Tokens explained.

For all of these, cookies are cleaner than fingerprinting and more privacy-respectful (users can clear them).

What’s Next: Privacy Sandbox

Chrome’s “Privacy Sandbox” is an attempt to provide alternatives to third-party cookies for legitimate ad/measurement use cases — Topics API, FLEDGE, Attribution Reporting. The idea: privacy-preserving APIs that allow personalization and measurement without per-user tracking.

Adoption is mixed. Browser-vendor support varies. The space is still evolving in 2026.

TL;DR

Cookies are the traditional way to track users; easy to clear; mostly dead for cross-site tracking.
Browser fingerprinting identifies users by browser characteristics; can’t be cleared.
30-50+ bits of entropy make fingerprints surprisingly unique.
Server-side signals (TLS / TCP / HTTP) add additional fingerprinting.
Tor and Brave mitigate fingerprinting via homogenization and noise.
Legitimate uses include fraud detection, bot prevention, account security.
GDPR / CCPA treat fingerprints as personal data.
Use libraries like FingerprintJS; combine with server-side signals; disclose to users.

The shift from cookies to fingerprinting is one of the major privacy trends of the past decade. Cookies’ decline was a clear user-privacy win; fingerprinting’s rise is more ambiguous. For application developers, the practical takeaway: combine first-party cookies (for authentication and sessions) with fingerprinting (for fraud/abuse signals) and respect user privacy throughout. For related fingerprinting topics, see passive OS fingerprinting and bot detection strategies.

Tracking Cookies vs Browser Fingerprinting