Browser Fingerprint Test Results Are Easy to Misread

It combines observable signals.

A site asks the browser and device for ordinary rendering, hardware, language, time-zone, screen, and network details, then combines those values into an identifier that can follow similar visits.

Some properties arrive directly through JavaScript APIs or HTTP headers. The user-agent can disclose the browser type and version, although modern browsers increasingly reduce its detail. Other values are inferred by asking the machine to perform work. A canvas test, for example, draws text or shapes and hashes the resulting pixels; tiny differences in fonts, graphics drivers, operating systems, and rasterization can alter that hash.

The resulting fingerprint is usually a record of features, not a magical serial number. Mozilla's definition of browser fingerprinting↗ covers the central trick: apparently minor characteristics become identifying when collected together.

That distinction matters. Two devices can produce the same fingerprint, while one device can produce different fingerprints after an update, monitor change, font installation, or settings change. Tracking systems may also combine the fingerprint with an IP address, account login, first-party storage, or behavioral data. The combination does the identifying.

Tests sample several layers.

A serious test checks directly reported settings, rendering behavior, available APIs, and network-facing details because no single signal remains stable or distinctive across every browser and device.

Common browser fingerprinting techniques include:

• User-agent and client hints, which report parts of the browser, platform, and device profile.
• Screen resolution, color depth, pixel ratio, and available viewport size.
• Language, locale, time zone, calendar, and number-format behavior.
• Canvas fingerprinting, where rendered pixels are hashed.
• WebGL renderer details and graphics output.
• Audio processing output from the Web Audio API.
• Font detection based on text dimensions rather than a direct font list.
• Touch support, CPU thread count, memory hints, media capabilities, and enabled features.
• TLS, HTTP, and IP characteristics visible to the server rather than JavaScript.

Permissions change the picture. A page cannot freely read every sensor or hardware identifier, but it can collect many low-entropy clues without showing a prompt, which is why the W3C fingerprinting guidance↗ asks specification authors to consider how APIs expose identifying information.

Tests differ substantially. One may hash only JavaScript properties, while another adds server-side headers and network data; comparing their uniqueness percentages as though they measured the same population is bad arithmetic.

It proves very little.

The result shows which data that particular page could observe at that moment and how common the assembled fingerprint was within that service's own sample, not across the entire internet.

A label such as “unique” usually means no matching fingerprint appeared in the test database or comparison window. It does not mean the test identified your name, proved that only one device has those settings, or established that every tracker can recognize you. The sample may overrepresent privacy-conscious users, desktop browsers, particular countries, or people who deliberately visit fingerprint test sites.

Uniqueness is population-dependent. A configuration can look rare among visitors to one test and ordinary among millions of Android devices running the same browser build. Small samples also turn mundane combinations into apparently exotic fingerprints.

Conversely, “not unique” is not a clean bill of health. A tracker can correlate a partly shared fingerprint with cookies, an account, IP history, page activity, or timing information. EFF's Cover Your Tracks methodology↗ explains that its statistics concern the browser population observed by the project, a qualification that belongs beside every rarity score.

Treat the score as diagnostic data. It can reveal an unusual screen size, exposed graphics renderer, rare extension effect, or unstable setting. It cannot certify anonymity.

They solve different problems.

Clearing cookies removes stored identifiers, and private mode limits what persists after the session, but neither action necessarily changes the fonts, graphics behavior, screen properties, locale, or APIs visible while pages are open.

Cookies are values a site stores and receives later. A fingerprint is reconstructed from current observations, so deleting storage can leave the recipe intact even though the old cookie jar is gone. Private browsing may block or partition more tracking features, depending on the browser, yet it still must render pages and expose enough system capability for sites to function.

Extensions can backfire. A rare mixture of blockers, modified headers, disabled APIs, and custom fonts may make one browser stand out more clearly, especially when each tweak changes a detectable feature. Randomized values have another failure mode: if they change within one session, inconsistency itself can become a signal.

Browser makers therefore tend to combine storage restrictions with standardization, partitioning, API limits, or carefully scoped noise. Firefox documents several such fingerprinting protections↗, including protections that may alter site behavior.

The practical rule is blunt: private mode is useful for keeping local history and session data separate, but it is not an anonymity mode. A VPN also changes the visible IP address, not the complete fingerprint.

Look for outliers first.

Use the report to find unusually revealing or unstable signals, then prefer a widely deployed browser's built-in protections over a hand-built pile of extensions that creates a rare configuration.

Start by separating three questions:

• What data was exposed, such as WebGL renderer, canvas output, user-agent, screen resolution, or time zone?
• Which values were genuinely unusual in the test's stated population?
• Did the fingerprint remain stable after restarting the browser, changing windows, or applying an update?

Do not chase a perfect score. Blocking every API can break video calls, maps, media playback, authentication, and accessibility features, while unusual breakage settings may identify the browser more readily. Uniformity often protects better than novelty, which is the reasoning behind browsers that try to make many users look alike.

A sensible order is to enable the browser's standard tracking protection, keep the browser and operating system current, remove unnecessary extensions, decline unneeded permissions, and separate identities into distinct browser profiles. Use Tor Browser when the threat model requires stronger anti-fingerprinting and network anonymity; changing dozens of its defaults defeats much of its crowd-based design.

Retest only to verify a change. The useful result is not “unique” or “safe,” but a clear account of which features remain exposed and which protection caused a site to stop working.