Browser fingerprint test

How this test works

A fingerprint has two layers, and this page shows both.

The passive layer is what our server sees before any script runs. Your browser's request carries the user agent string, the client hint headers that modern browsers send in its place, the Accept, Accept-Language and Accept-Encoding headers, the Sec-Fetch headers that describe how the page was requested, and a few optional ones such as Do Not Track or Save-Data. We list those headers, parse the user agent into browser, engine, operating system and device type, and hash the whole set into a short passive fingerprint. Any site can log this from an ordinary page view; no script, no permission, no cookie.

The active layer is what the page script collects once it runs. Each row of the ledger is one signal:

Every value is computed in your browser. The row fills in as each signal finishes, the combined hash appears at the top, and the run button recomputes everything so you can check whether the result is stable. The canvas fingerprint page shows the canvas drawing itself at full size if you want to see what is being hashed.

How to read your result

The page gives you three things to look at, in this order.

Stability. Press run again. On a browser with no randomization the hash is identical every time. If it changes, a setting or an extension is altering a value on each run, and the row whose value changed is the one being randomized, most often canvas or audio. Randomization defeats tracking across sites, which is its purpose, and it also makes the browser look like one that randomizes, which strict sites treat as a signal in its own right.

Consistency. Read the values against each other and against the connection. The platform in the client hints should match the operating system in the user agent. The WebGL renderer should be a GPU that exists on that platform; a mobile GPU on a desktop user agent, or a software renderer on a machine claiming a gaming card, is a mismatch. Touch points should fit the device type. The time zone and languages should fit the IP's country, which the anonymity score checks for you with point values. The fonts list should look like the operating system it claims: Windows fonts on a Windows user agent, Apple fonts on macOS.

Rarity. We do not show a uniqueness percentage, because we would have to invent it; a percentage needs a population to compare against, and a single visit does not provide one. Instead, read the notes next to each row. A screen size shared by many laptops, a current browser version and a common GPU are unremarkable. A rare resolution, an old browser version, an unusual font set or a renderer string with a non-standard name are the values that make a fingerprint stand out.

For someone checking a setup before a login, the practical reading is: the hash should be stable, the values should agree with each other and with the IP, and nothing should be rare for no reason. Being unidentifiable is not achievable in a normal browser; being unremarkable and consistent is.

How to fix it

What to change depends on what you want.

If you want less tracking across sites in everyday browsing:

1. Use a browser that limits fingerprinting by design. Firefox with its resist-fingerprinting option, enabled through about:config as privacy.resistFingerprinting, standardizes many values; Brave randomizes canvas, WebGL and audio per site by default. Expect the hash here to change between runs when randomization is on, which is the intended effect.
2. Keep extensions few. Each extension that changes page behavior adds a detectable trait, and fingerprint-spoofing extensions often produce impossible combinations that are easier to spot than the values they hide.
3. Keep the browser updated. A current version is shared by many people; an old one is rare.
4. Avoid resizing the window to unusual sizes, and avoid custom font installs if you care about this; both add rarity.

If you check a proxy or VPN setup before logging into an account:

1. Make the time zone match the IP's country. On Windows, Settings, then Time and language, then Date and time; on macOS, System Settings, then General, then Date and Time; on Android and iOS, the Date and time settings; in an antidetect browser, the profile's time zone setting, preferably derived from the proxy automatically.
2. Put the IP country's language first in the browser language list, or leave English first, which the score always accepts.
3. Turn off canvas or audio randomization in that profile, so the hash is stable across reloads. Randomization is a privacy tool for anonymous browsing and a liability for a session that should look like one returning user.
4. Do not spoof the user agent with an extension. Client hints, WebGL and fonts will contradict it, and the contradiction is worse than an honest user agent.
5. Reload this page from the same profile and check that the hash did not change and the values still agree.

If you use an antidetect browser:

1. Prefer profiles built from real device data over hand-edited values. The renderer, platform, fonts and screen should come from one coherent device.
2. Match the profile's operating system to the user agent and client hints it sends, and match the time zone and language to the proxy's country.
3. Set WebRTC to replace the public address with the proxy address rather than disabling it; see the WebRTC leak test.
4. Run this page inside the profile twice. The hash should be identical both times, and every row should show values plausible for the claimed device. Then run the anonymity score for the IP-side checks.

If you develop for the web and want to see what you are handing to third-party scripts, the passive table shows which headers your browser sends with every request, and the HTTP headers page shows the full set, including cookies and referer, for debugging.

Limits of this test

• No uniqueness measurement. We do not keep a population of fingerprints, so we cannot tell you how many browsers share yours, and we will not print a made-up percentage. Services that claim one are comparing against their own visitors, which is a different population from the site you care about.
• The hash is ours. Every fingerprinting script combines different signals in a different order, so your hash here will not equal your hash anywhere else. Compare hashes only within this page: between runs, between profiles, between devices.
• Signals we do not collect. Network-level fingerprints such as TLS and TCP characteristics, the HTTP/2 settings your browser negotiates, media device lists, battery and sensor APIs, and behavioral signals such as typing rhythm are all used by some sites and are outside this test.
• Extensions can hide or distort values. A spoofing extension changes what the script reads; the test shows the spoofed value and cannot always tell it is spoofed, though contradictions between rows often reveal it.
• Rarity notes are rules of thumb, not statistics. They flag values that are uncommon in general, not what a particular site has seen.
• Fingerprints are one of several identifiers. Cookies, logged-in accounts and device identifiers in native apps identify you regardless of the fingerprint. A consistent, unremarkable fingerprint helps a login pass; it does not make you anonymous.

Why consistency matters more than uniqueness for a login

Tracking and fraud detection use fingerprints differently. A tracker wants a stable value to recognize you across sites; against that, randomization and standardization work. A login system wants to know whether this session is the same person as last time and whether the story the browser tells is plausible; against that, randomization hurts, because the fingerprint changes on every visit and never matches the account's history, and spoofing hurts, because it produces combinations no real device has. The checks that strict sites run are cross-checks: user agent against client hints, platform against GPU, fonts against operating system, time zone and language against IP. A common laptop with its real values, a clock set to the proxy's zone and a stable hash passes those; an elaborately spoofed browser often fails them. That is why this page reports consistency and stability rather than a uniqueness score.

What each signal reveals

Canvas and WebGL mostly identify hardware: the graphics card, the driver and the font rendering stack. They are stable for years on the same machine, which is what makes them valuable to trackers.

Audio identifies the platform's audio processing; it varies less than canvas but adds a few bits.

Fonts identify the operating system and what has been installed on it. A design professional's machine, a machine with East Asian language packs and a fresh install all look different.

Screen identifies the device class and sometimes the model. Pixel ratio combined with resolution narrows a phone down to a few models.

Time zone and languages identify where and in what language the device is used. They are the two signals most often inconsistent with a proxy, and the two that are easiest to fix.

Client hints carry the detail that Chromium browsers removed from the user agent string: the exact browser version, the platform and its version, the CPU architecture and, on mobile, the device model. They are the modern form of the user agent and are compared against it.

Plugins and touch identify browser family and device type, and contribute mainly as cross-checks.

Client hints are replacing the user agent string

Chromium-based browsers now send a reduced user agent string that freezes the operating system version and most detail, and expose the detail through client hint headers instead, some sent by default and some only when a site asks. The passive table on this page shows which hints your browser sent. For fingerprinting this changes little: the same information is available, just in a different place. For consistency checks it matters, because a user agent edited by an extension usually leaves the client hints untouched, and the two then disagree. The user agent page parses your string and lists the hints next to it so you can confirm they match.

Checking that two profiles look like two devices

People who run several accounts from one machine, each in its own browser profile, have a specific question this page can answer: do the profiles look like different devices, or like one device with different cookies? Open this page in each profile and compare. The combined hash should differ between them, and the differences should come from values that genuinely vary between machines, such as canvas, WebGL renderer, screen and fonts. If two profiles share the same canvas and WebGL hashes and differ only in user agent and time zone, a site that reads the canvas sees one machine. Within each profile, the hash should be identical on every run and on every day; a profile whose hash drifts between visits looks like a new device each time, which triggers verification on strict services. Fix drift by turning off randomization in that profile and by not changing the browser version, display scaling or font set between sessions. Then confirm the connection side separately: each profile's proxy should pass the IP checker, and its time zone and language rows should pass the anonymity score, so that the device story and the network story agree.

Does private browsing or clearing cookies help?

Not against fingerprinting. Private windows and cookie clearing remove stored identifiers, and a fingerprint is not stored; it is recomputed from the same hardware and settings on every visit. The practical defenses are the ones above: a browser that standardizes or randomizes values, fewer extensions, and for login use, a consistent profile that does not change between visits. The browser fingerprint glossary entry goes further into how fingerprints are built and used.