How browser fingerprinting works

Fingerprints vs cookies: what changes when storage is blocked

A cookie is an explicit label the server (or script) writes to your browser storage. You can see it in devtools, delete it, or block third-party writers entirely. A fingerprint is inferred: JavaScript queries APIs and hashes the results. No single field says "user ID 88421"; the ID emerges from the combination.

That matters for regulation and UX. Cookie banners address stored identifiers; fingerprinting often runs without equivalent disclosure. Browsers have responded with fingerprint resistance — Safari's Intelligent Tracking Prevention, Firefox's resistFingerprinting mode, Brave's farbling — that add noise or standardize values so fewer users look unique.

Site operators collecting analytics should document what they measure. Our privacy policy describes how Solana Garden handles visitor data on content pages; any product that fingerprints users for fraud or ads should be at least as explicit about purpose and retention.

Entropy sources: what scripts actually measure

Each signal adds entropy — bits of uniqueness. Common sources:

• Canvas and WebGL. Draw text or a 3D scene, read back pixels or renderer strings (WEBGL_debug_renderer_info). GPU drivers and font smoothing differ subtly between machines.
• AudioContext. Oscillator output processed through the audio stack yields a hash that varies by OS and hardware.
• Fonts and plugins. Legacy techniques probed installed fonts via CSS width measurements; plugin lists are largely gone in modern browsers but language and font enumeration still leaks.
• Screen and hardware. Resolution, color depth, device memory, CPU core count, touch support, and whether you prefer dark mode.
• Network stack. TLS ClientHello fingerprints (JA3/JA4) identify client libraries at the connection layer — useful to CDNs and bot detectors, invisible to page JavaScript but visible to intermediaries.
• Behavioral timing. Keystroke cadence and mouse movement are not classic browser fingerprinting but combine with device signals in fraud scores.

Vendors concatenate normalized values, hash them (SHA-256 is typical), and store the digest. On your next visit, they recompute and match. Collisions happen — two users with identical MacBook configs may share a fingerprint — but commercial systems optimize for "good enough" uniqueness across millions of daily users.

Cross-site tracking and the third-party problem

First-party fingerprinting on bank.com helps that bank detect session hijacking. The privacy fight is third-party use: an ad script embedded on thousands of sites computes the same fingerprint everywhere, building a cross-site profile without cookies. That bypasses cookie blocking and survives incognito windows on the same device profile.

Browser vendors counter with storage partitioning (each site gets isolated storage and sometimes isolated network state) and by restricting high-entropy APIs behind permissions or noise injection. Chrome's Privacy Sandbox proposes topics and protected audiences as ad-tech alternatives; fingerprinting is explicitly disallowed in those frameworks — though enforcement is an arms race.

Authentication design intersects here: origin-bound credentials like passkeys reduce password phishing but do not stop passive fingerprinting on pages you merely read. Logging in still gives the site a declared identity on top of whatever passive ID they already inferred.

Fraud detection vs surveillance

Not every fingerprint is for ads. Payment processors and crypto exchanges fingerprint browsers to flag bot signups, credential stuffing, and multi-account abuse. The same canvas hash that irritates privacy advocates helps a merchant decide whether a card-not- present charge looks like a scripted attack.

The trade-off is proportionality. A login rate limiter needs coarse signals; selling those signals to data brokers does not follow. Users connecting wallets face parallel risks — malicious sites can fingerprint while requesting signatures. Our Solana wallet security guide covers seed phrase hygiene and transaction preview; pairing that with browser choice and extension discipline reduces exposure when you interact with high-value flows.

What actually helps users (and what does not)

Often useful:

• Privacy-focused browsers (Firefox with strict protection, Brave, Tor Browser) that randomize or block fingerprinting APIs.
• Browser compartmentalization — separate profiles or containers for work, shopping, and crypto so fingerprints do not trivially link contexts.
• Limiting extensions — ad blockers and password managers change the fingerprint; that can be good (blocking trackers) or bad (rare extension combos make you more unique).
• Rejecting unnecessary permissions — camera, mic, and precise location are separate from canvas fingerprinting but add identifying signals when granted.

Oversold:

• VPN alone. Hides IP address but leaves browser entropy intact; many VPN users are trivially fingerprintable.
• Clearing cookies only. Fingerprint match survives if the script runs again on the same device profile.
• User-Agent spoofing extensions without holistic resistance — inconsistent headers can increase uniqueness.

Web developers sometimes confuse fingerprinting with cache busting — appending content hashes to static asset URLs so CDNs fetch fresh CSS. That "fingerprint" is intentional and public; see our HTTP caching guide for how style.a1b2c3.css filenames differ from tracking identifiers.

How sites implement fingerprinting (and how to spot it)

Commercial fingerprint libraries (FingerprintJS and similar SDKs) ship a few kilobytes of JavaScript that runs on page load. They batch API calls inside requestIdleCallback or after the first paint so Core Web Vitals stay acceptable while entropy collection proceeds in the background. The SDK POSTs a JSON blob to a vendor endpoint; the server returns a visitor ID your analytics pipe treats like a cookie ID.

In browser devtools, watch the Network tab for requests to unfamiliar domains immediately after load, and the Sources tab for minified bundles referencing canvas, webgl, or offlineAudioContext. Privacy extensions (uBlock Origin, Privacy Badger) often block known fingerprint hosts; that is a signal the page attempted collection. Legitimate fraud vendors sometimes self-host the script under a first-party path to evade blocklists — review your own dependencies if you inherit a CMS theme or tag manager you did not configure.

If you operate a site, ask whether you need a stable cross-session ID at all. Session analytics without persistent identity, server-side rate limits keyed by IP plus account, and step-up auth for sensitive actions often cover fraud use cases without canvas probes.

Regulatory and platform direction

GDPR and ePrivacy treat persistent device identifiers as personal data when they can single out a person. France's CNIL and other DPAs have fined sites for fingerprinting without valid consent. Apple's App Tracking Transparency does not govern Safari web directly, but Safari's ITP aggressively curtails cross-site identifiers — pushing ad tech toward first-party data and SKAdNetwork-style aggregates on mobile.

For publishers relying on display ads (including this site), the sustainable path is first-party content and transparent data practices — not covert high-entropy fingerprinting that risks account sanctions from ad networks and erodes reader trust. Measure what you need for security and operations; document it; delete when the purpose ends.

Fingerprinting will not disappear — entropy is too useful for fraud and analytics. But the gap between "technically possible" and "socially and legally acceptable" keeps narrowing. Users who understand canvas hashes and partitioned storage make better choices about browsers, extensions, and which sites deserve wallet access.

Related on Solana Garden: Privacy policy, Passkeys and WebAuthn, Solana wallet security, More explainers.