To test your browser fingerprint, open a fingerprint test page in the browser you want to check, let it finish, then read two things: the values it collected, and whether those values agree with each other. The values show what any website can read. The agreement, or the lack of it, is what detection systems actually weigh.
This guide walks through our free browser fingerprint test section by section: what each row means, what each of the fifteen consistency checks compares, the usual causes when one turns amber, and how to compare two runs so you can test browser profiles, a VPN or a new setting properly.
What a fingerprint test can tell you, and what it cannot
A good test answers one useful question: what does a page see, and does it add up? It reads the same values a fingerprinting script reads, hashes the ones that stay the same between visits into an ID, and cross-checks them.
It cannot tell you how rare you are. That needs a database of other visitors' fingerprints, and our test keeps none, which is why it describes what makes you identifiable instead of printing a "1 in N" figure. A page script also cannot see three things a server sees: your IP address, the TLS and HTTP/2 handshake your browser sends, and your behaviour over time. Keep those in mind before you read a clean result as the whole picture.
The test runs entirely in your browser. It makes no network request after the page loads, saves nothing and sends nothing, which matters when the thing you are testing is your own privacy.
Step by step: run the test
- Open the browser fingerprint test in the browser or profile you want to check. Close DevTools first; an open console is itself something the test notices.
- Wait a second or two for the progress bar to finish. The summary at the top shows a fingerprint ID, a one-line verdict and a short list of what makes you identifiable.
- Read the Consistency section first. Each check is green, amber or skipped, with a sentence explaining what it found.
- Scroll through the reading sections underneath. They hold every value behind the checks.
- Choose Download JSON to keep the run. You will need it to compare.
Reading the sections
The readings are grouped in the order a fingerprinting script usually collects them.
Identity basics
The user agent, the older navigator.platform value, the client hints (a newer, structured copy of the user agent that Chrome-based browsers send), your language list, the locale used to format dates and numbers, your timezone and its UTC offset. Two client-hint rows, OS version and processor, are "high-entropy": a page has to ask for them explicitly. Check that the operating system and version agree everywhere they appear.
Screen and window
Screen size, available area, pixel density and colour depth, plus the window and viewport. Window size is left out of the ID because it changes when you resize. The useful row here is CSS media queries agree: it tells you whether the size and density CSS sees match what scripts read.
Hardware
Logical processors, device memory (rounded and capped by the browser on purpose), touch points and the primary pointer. Each value is weak alone because few values are possible. They matter in combination with the device the user agent claims.
Graphics and audio
The canvas hash, the WebGL hash and limits, the WebGL vendor and renderer (including the "unmasked" names that identify the actual GPU), and whether WebGPU is present. Audio is a short silent sound rendered offline and hashed. Both canvas and audio are drawn twice; the stable on re-read rows say whether the two readings matched.
Fonts, media devices and automation tells
Which of a list of common Windows, Mac and Linux fonts are installed, counts of cameras, microphones and speakers, storage and plugin details, and the automation tells bot checks start with: navigator.webdriver, "Headless" in the user agent, a missing window.chrome, values set directly on navigator, and whether something is reading the console.
Reading the consistency checks
The fifteen checks fall into four groups. Knowing the group tells you where to look when one turns amber.
| Group | Checks | What an amber result usually means |
|---|---|---|
| Identity | User agent vs platform, user agent vs client hints, language list vs locale | The user agent was changed in one place only, often by an extension |
| Place | Timezone vs clock offset, timezone vs language | A timezone set by a script, or a proxy whose timezone was copied without the language |
| Device | Screen vs window, touch vs device type, graphics vs operating system, fonts vs operating system | An emulated device that does not match the real hardware underneath |
| Tampering | Built-in functions untouched, page vs Web Worker, page vs iframe, stable readings, no automation flags, plugin list shape | A script layered on top of the browser, added noise, or an automation tool that leaves flags |
A few of these deserve a word of explanation.
Built-in functions untouched asks nearly forty built-in getters and methods for their source code, using a clean copy of toString from a fresh iframe. A function a script replaced no longer reads as native code, and the test names it.
Page vs Web Worker and page vs iframe read the user agent, platform, languages, processor count and more from three places. A change applied only to the page shows up as a difference.
Graphics vs operating system catches combinations that cannot exist on real hardware, such as a Direct3D renderer on a Mac or an Apple GPU on Windows.
Timezone vs language is deliberately soft. Travellers and expats have mismatches all the time, so the test reports it as information rather than a warning.
An amber result does not mean you look like a bot. Privacy extensions, virtual machines, remote desktops and unusual hardware all cause mismatches. It means a site that runs this comparison would notice, and it points you at the setting to look at. For the reasoning behind each comparison and how to fix the common ones, see fingerprint consistency checks.
Comparing two runs
A single run is a snapshot. Most real questions are comparisons: does this VPN change anything, are these two profiles really separate, does my profile keep the same fingerprint after a restart?
- Run the test and choose Download JSON.
- Change one thing: switch profile, connect the VPN, restart the browser, or change a setting.
- Run the test again, then paste the first file into the Compare box (or open it from disk) and choose Compare with this run.
- Read the list of readings that changed.
The comparison also runs entirely in the page. What you want to see depends on the question:
- Two separate profiles should have different fingerprint IDs.
- The same profile after a restart should keep its ID. If it changes on every load, the stable-readings check will usually tell you that canvas or audio noise is the cause.
- A VPN or proxy should change nothing in the readings at all, because it changes your network address, not your browser. If your timezone and languages stay at home while your address moves abroad, that is a contradiction a server can see even though this page cannot.
Testing a profile the way it will run
If a profile will be driven by a script or an AI agent, attach your automation first, then load the test, so the automation checks see the browser as a site will. If it will run headless, test it headless: headless browsers have often differed from windowed ones in their screen, plugin list and permission answers, which is what the plugin-list and automation checks look for.
How Browz does on this test
We run the same test against every Browz release, in a normal window and headless, and publish the result. On 13 November 2026, Browz 0.1.9 on macOS passed 15 of 15 consistency checks in both modes, and the same test found no inconsistencies on Windows or Linux. The result and the test's raw JSON are linked from the anti-detect page, so you can read every value we read.
Three things make that result possible:
- Values set in the engine. Browz changes what a site reads in the browser engine's own code, so there are no replaced functions to find, and the page, its workers, its iframes and the request headers all get the same answer. Our explainer on engine-level fingerprint protection shows which checks separate the two approaches.
- One device per profile. Each profile's platform, screen, fonts, graphics and languages are chosen together and stay the same between sessions, and the profile's timezone and languages come from its proxy's measured exit.
- Automation leaves no trace in the fingerprint. Driving a profile with Playwright, Puppeteer or an AI agent over MCP does not change the device it presents, which is why the headless run passes the same checks as the windowed one.
To check it yourself, open the test in a Browz profile and in your everyday browser, download both runs and compare them. Then compare two Browz profiles: they should show two different IDs, each stable after a restart. The fingerprint policies article explains what each profile varies.
Frequently asked questions
Is it safe to run a browser fingerprint test?
Ours is. It runs in your browser, makes no network request after loading, and saves nothing on our servers or in your browser's storage. The results exist only in the page until you copy or download them. Other test sites differ, so read how a test handles your data before you use it.
Why does my fingerprint ID change every time I reload?
Usually because the browser adds random noise to canvas or audio readings, a privacy feature in some browsers. The stable-readings check tells you whether that is the cause. A browser update, a new graphics driver or a different screen also changes the ID.
Does a clean result mean a website cannot recognise me?
No single test can promise that. A clean result means the values a page can read agree with each other. Sites also use your IP address, cookies, the TLS handshake and your behaviour, none of which a page script can see. Keep each identity in its own profile with its own proxy for the parts a test cannot show.
How do I check whether two browser profiles are really separate?
Run the test in each profile, download both JSON files and use the Compare box. Separate profiles should have different fingerprint IDs and different canvas hashes, and each should keep its own ID after a restart. Check their IP addresses separately, since the test does not see them.