Client-Side Fingerprinting: What Your Browser Reveals Before You Log In
The term client-side fingerprinting describes the practice of collecting device and browser signals with JavaScript running inside the page you loaded — canvas output, WebGL renderer strings, audio processing, installed fonts, screen metrics and timing — then hashing them into an identifier the site stores and compares on your next visit. The collection runs on your machine before anything reaches the server, which is why it survives cookie clearing.
📌 TL;DR Executive Summary
- Core Takeaway: Client-side fingerprinting reads dozens of weak browser attributes in JavaScript and combines them into a hash stored on the site’s servers. A fingerprint is a composite; no single signal identifies you, the stack does.
- Key Risk/Challenge: The hash never lives on your device, so clearing cookies, using private windows or switching networks changes nothing. Sites fuzzy-match too, so a browser update does not break the identifier.
- Recommended Solution: Measure your own fingerprint first, then keep one consistent browser configuration per working profile — browser, screen, timezone, locale and proxy aligned — instead of randomising settings page by page.
What Client-Side Fingerprinting Actually Covers
Understanding what a browser fingerprint is starts with one idea: it is a composite of individually boring attributes. Timezone alone splits users into a few dozen buckets; a canvas hash splits them into thousands. Stack screen metrics, GPU strings, font lists and audio output on top and the combination approaches uniqueness for the device.
The name describes where the work happens, not who does it. Client-side means the script runs in your browser engine and reads values the browser exposes to any page. Server-side means the site inspects what arrives at the network layer — TLS handshake shape, IP, header order — where you have far less ability to see or change it.
The two layers respond to different fixes. Blocking a JavaScript API changes the client-side picture; changing your network path changes the server-side one. Most people harden one and never check the other.
One more split to hold in your head: first-party fingerprinting runs from the site you visited, usually for analytics, fraud checks or personalisation. Third-party fingerprinting runs from embedded code and feeds cross-site advertising and monitoring. Same technology, different accountability.
How Client-Side Fingerprinting Works Under the Hood
In EFF’s 2026 survey of the Tranco top 10,000 sites, instrumented sessions were flagged by canvas, WebGL renderer, audio-context, font enumeration, hardware-concurrency and timing techniques within 90 seconds of page load. That window says most of what you need to know about how the pipeline is built.
Collection: ninety seconds of JavaScript
The script loads early, usually inline or in the first bundle, and runs a battery of reads. None require a permission prompt; each returns a value the browser has to expose for legitimate reasons — rendering a graphic, reporting available CPU threads, listing fonts for layout. Individually, every value is a few bits of entropy. Combined, they cross the threshold.
Canvas: the graphics pipeline as a signature
The script draws text and shapes onto a hidden canvas and reads the pixels back. Identical instructions produce slightly different pixels on different machines, because output depends on your GPU driver, your operating system’s text rendering (GDI+ on Windows, CoreText on macOS, FreeType on Linux) and your display colour profile. The result clusters devices by shared configuration, which is why canvas fingerprinting techniques keep working after a browser reinstall — the rendering stack did not change.
WebGL and WebGPU: the GPU names itself
WebGL goes further than pixels. The WEBGL_debug_renderer_info extension exposes GPU vendor and renderer strings in plain text. Published entropy measurements put WebGL at 8–13 bits on the sites that use it, comparable to what the whole user agent carries. WebGPU, stable in Chromium 113 and later, adds adapter feature flags, texture format matrices and compute timing on top of that.
Audio, fonts and timing
AudioContext fingerprinting routes an oscillator through a compressor and reads the resulting buffer, which shifts with the audio stack and floating-point behaviour. Font enumeration measures rendered text width against fallbacks to work out which fonts you have installed — designers, developers and office workers install very different sets. Timing probes catch hardware class and, sometimes, virtualisation.
Hashing, matching and the confidence score
Collected values are hashed and stored on the site’s servers, not on your device. That one architectural fact explains why clearing cookies does nothing. The loop is: collect, hash, compare against stored hashes, identify.
Modern systems do not need an exact match. They fuzzy-match, tolerate drift after a browser update, and return a confidence score beside the visitor ID — a score like 0.94 means “probably the same device, something moved”. AmIUnique, the INRIA study, found 89% of fingerprints stayed uniquely identifiable over 90 days and 81% at 180 days, while evolution tracking restored continuity for 91% of prints that had changed. A single hash is a snapshot; the fuzzy match is the identity.
First-party delivery beats the blocklists
Fingerprinting scripts served from the site’s own domain are much harder for ad blockers and privacy extensions to strip, because blocking them means blocking the site. Combined with fuzzy matching, that is why extension-only defences degrade quietly: you feel protected and the identifier still resolves.
Client-Side vs Server-Side Signals: What Each Layer Can See
The two layers differ in what they capture and in how much you can influence. The right-hand column is the practical one.
| Layer | What it captures | Where it runs | How visible to you |
|---|---|---|---|
| JavaScript APIs | Canvas, WebGL/WebGPU, audio, fonts, screen, hardware concurrency | Your browser engine | High — any devtools session shows it |
| HTTP headers | User agent, Accept-Language, Client Hints, header order | Your browser | High |
| Timing and behaviour | Operation durations, input cadence, request rhythm | Both | Low |
| TLS handshake | Cipher and extension counts, ALPN, ClientHello order (JA3/JA4) | Your network stack | Very low |
| IP and routing | Exit IP, ASN, coarse location, latency | Network path | Moderate |
The lower rows are the hard ones. JA4, released by FoxIO in 2023 as the successor to JA3, captures TLS 1.3 ClientHello parameters in original transmission order and is deployed at wire speed by Cloudflare, Fastly and Akamai. Cloudflare and Fastly expose handshake identifiers to customers through custom request headers; as of 2026, native AWS ALB does not. A single JA4-style hash lookup identifies a large share of naive automated traffic, depending on how popular a scraping target the site is — a statement about default tooling, not about any individual visitor.
Why Client-Side Fingerprinting Matters Now
It is on most of the top sites
EFF’s 2026 survey put fingerprinting on 78% of the Tranco top 10,000, up from 61% in 2024. EFF ties the jump to the ad stack shifting to fingerprinting after Chrome completed third-party cookie deprecation in late 2025, following several delays. Treat the figure as one survey result rather than a settled standard, and the direction as the signal: the cookie going away pushed identification into the page.
Fingerprints outlive cookies
A cookie is a file you can delete. A fingerprint is a server-side record keyed to attributes you did not choose and mostly cannot see. Clearing storage removes the site’s ability to greet you by name; it does not remove its ability to recognise the device.
Who it affects most
For a freelancer with one laptop and one set of accounts, fingerprinting is mostly an advertising and analytics concern. For someone running several client storefronts, brand accounts or regional test logins from one machine, it becomes operational: one shared browser environment means shared cookies, shared storage and a single stored fingerprint record, so a crossed sign-in or a stale session leaks across client work.
QA and support teams hit a different edge of the same problem. Reproducing a bug or a regional checkout flow needs the browser to behave like the user’s browser, not merely carry a swapped user-agent string.
The legal footing splits by purpose
Under GDPR the test is lawful basis and proportionality to a genuine security aim, so fraud prevention and advertising fingerprinting sit on very different ground. CCPA turns on disclosure and how opt-outs are handled. None of this is legal advice; the point is that “fingerprinting is legal” and “fingerprinting is illegal” are both wrong, because purpose decides.
How Much Your Browser Choice Changes Uniqueness
Published comparisons of fingerprint entropy put browsers in fairly wide bands. The figures below come from one comparative dataset drawn from different populations and techniques, so read them as indicative ordering rather than precise measurement.
| Browser setup | Approx. share of users uniquely identified | Approx. identifying bits |
|---|---|---|
| Tor Browser | Under 5% | 3–5 bits |
| Brave, default shields | 20–35% | 8–12 bits |
| Firefox, hardened settings | 45–55% | 12–14 bits |
| Safari | 60–70% | 13–15 bits |
| Firefox, default | 65–75% | 14–17 bits |
| Edge, default | 78–88% | 15–19 bits |
| Chrome, default | 80–90% | 16–20 bits |
The pattern is counter-intuitive until you state it plainly: the more your setup resembles a large group of other people’s setups, the fewer identifying bits you carry. Tor scores lowest because everyone on Tor deliberately presents the same shape. Firefox’s fingerprinting protection, in its stricter modes, randomises HTML5 canvas readback, restricts font visibility, cuts precision in some hardware and browser signals and limits what suspected fingerprinters see; Resist Fingerprinting tightens it further. At the other end, a default Chrome or Edge install carries 16–20 bits, enough to pin one device out of roughly a million. If you want the underlying maths, this explanation of browser fingerprint entropy walks through how bits accumulate across weak signals.
A Practical Checklist for Controlling Client-Side Signals
- Measure before you change anything. Run EFF’s Cover Your Tracks test and read the characteristics it reports. EFF notes the tool does not cover every tracking and protection method, but it gives you a baseline to re-run after each change.
- Decide what you are protecting. Everyday privacy browsing and “keep this client’s work in its own clean environment” need different fixes. The second is about separation and consistency, not concealment.
- Reduce the surface where it costs you nothing. Block known fingerprinters, keep the browser patched, remove extensions you do not use. Every extension that injects script widens your surface.
- Stop randomising. Pick one coherent configuration per working profile and keep it stable across sessions. Stability is what makes a setup ordinary.
- One profile per account. Separate cookie jars, separate storage, separate fingerprint settings. Never run two client accounts from the same profile and assume different logins are enough.
- Align network with locale. A browser claiming one country while the timezone and geolocation say another is the classic discrepancy a site notices. Keep IP, timezone, locale and language consistent.
- Re-test after browser updates. Engine updates shift canvas and WebGL output. That drift is normal and is what fuzzy matching absorbs — but you still want to know your baseline moved.
Common Mistakes That Make Fingerprinting Worse
Treating private mode as a reset button
Incognito clears local state at the end of the session. It does not change a single value the fingerprinting script reads, and the hash it produces matches the one from your normal window.
Rotating proxies inside one profile
Your fingerprint says “Chrome on Windows in Berlin” and your exit IP changes country every few requests. The mismatch is louder than either signal alone. If you need multiple regions, use multiple profiles, each anchored to its own network path.
Assuming a user agent override is protection
Changing the user agent string does nothing about canvas, WebGL or fonts. A UA that disagrees with what the rendering stack produces is a contradiction a site can detect, not a fix.
Hardening until the browser is bizarre
Disabling canvas entirely, blocking all fonts and freezing timers produces a configuration almost nobody else runs. You have traded a common fingerprint for a rare one. Balanced, mainstream-looking settings beat maximal ones.
Believing a single hash is the whole identity
Fuzzy matching with confidence scores means partial drift does not reset recognition. If you are relying on “my fingerprint changed, so I am new”, you are relying on how these systems worked several years ago.
Where Send.win Fits
Send.win is a browser profile manager, and it addresses the part of client-side fingerprinting most checklists cannot: running several profiles on one machine without them sharing a single browser identity. Each isolated profile carries its own cookies, storage, sessions, proxy and fingerprint settings, and that fingerprint — canvas, WebGL, audio, fonts, hardware — is handled inside the browser engine, so two profiles do not present one shared browser identity. Think of it as the same idea as the fingerprinting protection in Firefox or Brave, applied per profile instead of per site.
There are two ways to run it, and they are different products. Sendwin Browser is a native desktop app for Windows 10/11 (64-bit), macOS 12+ and Linux, built on Chromium and installed locally. Cloud browser profiles run on Send.win’s cloud server in Helsinki, Finland, from any device with nothing to install — a free demo gives you a three-minute preview without signing up.
For the coherence problem, the useful detail is that timezone, locale, WebRTC and geolocation follow the profile’s proxy exit IP automatically, so the gap between claimed location and browser-reported region closes on its own. Residential proxies are included on Pro and Team with metered bandwidth, and bring-your-own HTTP/SOCKS5 works too. Paid teammates can open a shared profile already signed in, and cloud sync moves logins between devices — which matters when the person covering an account is not the person who set it up.
Two limits worth stating plainly. Every profile is opened and used by hand in the browser, one session at a time, so the work stays manual from start to finish. And it is for accounts you own or are authorised to manage, following each platform’s terms; where a platform limits multiple accounts, use its official route, such as Amazon’s approval process for an additional seller account or Business Manager roles on Meta. This piece on browser fingerprinting and isolation goes deeper into how profile separation works.
🏆 Send.win Verdict
Client-side fingerprinting is not something you switch off — it is a property of the browser engine that any page can read. What you can control is coherence: whether each of your working profiles presents one stable, consistent configuration instead of a stack of contradictions. Send.win handles that at the profile layer, with per-profile fingerprint settings and network signals that follow the proxy, on the desktop app or in the EU cloud browser.
See Send.win plans — Pro from $19/mo (or $83.88/yr, which works out to $6.99/mo) with 150 profiles and 5 GB of proxy bandwidth a month, Team at $49/mo for 500 profiles, or start with the free cloud demo.
Frequently Asked Questions
Does clearing cookies stop client-side fingerprinting?
No. The hash is computed from browser and hardware attributes and stored on the site’s servers, not on your device. Deleting cookies removes stored local state, but the next page load regenerates the same or a near-identical hash and the fuzzy matcher resolves it to the same record.
What signals does client-side fingerprinting collect?
Typically canvas output, WebGL and WebGPU renderer details, AudioContext buffers, font enumeration, screen resolution and colour depth, hardware concurrency, timezone, language and various timing measurements. Each contributes a few bits; the combination is what identifies the device.
Can you prevent canvas fingerprinting entirely?
You can blunt it. Firefox’s stricter protection modes randomise canvas readback and restrict font visibility, and some extensions attempt the same. Blocking it outright tends to produce a configuration almost nobody else runs, which is itself distinctive, so balanced settings usually work better than maximal ones.
How stable is a browser fingerprint over months?
More stable than most people expect. The AmIUnique study found 89% of fingerprints remained uniquely identifiable over 90 days, with 81% still unique at 180 days, and evolution tracking restored continuity for 91% of prints that had changed. Browser updates cause drift, and fuzzy matching absorbs it.
Is client-side fingerprinting legal under GDPR?
It depends on purpose and lawful basis. Fingerprinting for fraud prevention is assessed differently from fingerprinting for advertising, with proportionality to a genuine security aim as the GDPR test, while CCPA focuses on disclosure and opt-out handling. Get jurisdiction-specific advice rather than relying on general statements.
What is a TLS fingerprint, and is it client-side?
A TLS fingerprint is derived from the shape of your handshake — cipher suites, extensions, ALPN and their order, as captured by formats like JA3 and JA4. It is generated by your network stack rather than page JavaScript, so it belongs to the server-side layer and is far harder to inspect or alter from the browser.
How do I test my own browser’s fingerprint?
Start with EFF’s Cover Your Tracks, which lists the characteristics a tracker sees and explains the identifying bits involved, then re-run it after any configuration change or browser update. EFF notes the tool does not cover every tracking and protection method, so treat it as a baseline rather than a verdict.
How Send.win Helps With Client Side Fingerprinting
Send.win is a browser profile manager for professionals and teams: every account gets its own isolated browser profile.
- Isolated profiles – separate cookies, storage and sessions per profile
- Fingerprint protection – each profile keeps its own consistent browser fingerprint, so profiles never share one browser identity
- Desktop app + cloud browser – native app for Windows, macOS and Linux, or run profiles in the cloud with no install
- Residential proxies included – on Pro and Team, with timezone and locale matched to the proxy
- Team sharing – share a signed-in profile with a teammate without sharing the password
Try the free cloud demo — no install — or download the desktop app. Paid plans start at $19/month, and your first card purchase is covered by a 7-day money-back guarantee (see pricing).