What is browser fingerprinting? How websites recognise your browser

Browser fingerprinting is a way for a website to recognise a browser from the details it reveals about itself: its user agent, screen size, timezone, languages, installed fonts, graphics card and the way it draws text and images. No single detail is unique, but together they often are. Because nothing is stored on your computer, clearing cookies or opening a private window does not change a fingerprint.

This guide explains what goes into a fingerprint, how websites use it, why a fingerprint that contradicts itself stands out more than a rare one, and how to test your own browser in a couple of minutes.

How a fingerprint is built

Every time a page loads, your browser answers dozens of questions, some in the request headers and many more to the page's JavaScript. A fingerprinting script collects the answers and combines them, usually into a hash. The common ingredients fall into a few groups.

A few of these deserve a closer look.

Canvas and WebGL

A page can draw text and shapes on an invisible canvas and read the pixels back. The result depends on the graphics card, the driver, the operating system's text rendering and the fonts installed, so two computers that look identical on paper often produce different images. WebGL does the same with 3D drawing and also exposes the names of the GPU vendor and renderer. These are among the strongest signals in a fingerprint. We go deeper in canvas fingerprinting explained.

Fonts

Pages cannot list your fonts directly, but they can measure a line of text in a font and compare it with a fallback. If the size changes, the font is installed. A Mac, a Windows laptop and a Linux desktop each have a very different set.

Timezone and language

The timezone your browser reports, the offset of its clock and the languages it prefers say a lot about where you are. On their own they are shared by millions of people. Next to an IP address in another country, they become a contradiction.

Network-level signals

Your IP address is not part of the browser fingerprint itself, but sites read it on every request. WebRTC, the technology behind video calls, can reveal addresses that a proxy would otherwise hide. And before any JavaScript runs, the way your browser opens a secure connection (its TLS and HTTP/2 settings) forms a fingerprint of its own.

What websites use fingerprints for

Fingerprinting is used for very different purposes, and it helps to keep them apart:

• Fraud and security. Banks, payment providers and sign-in pages use device signals to notice when an account is opened from an unfamiliar device, and to ask for an extra check.
• Bot detection. Services that protect sites from automated traffic compare what a browser claims with what it actually does. A browser that claims to be Chrome on Windows but behaves like an automation tool on Linux is easy to flag.
• Tracking and advertising. Some scripts use a fingerprint to follow people across sites without cookies. Privacy regulators in several countries treat this as personal data processing that needs a lawful basis.
• Linking accounts. When the same fingerprint signs in to several accounts, a site can conclude they belong to the same person or business.

That last point is why people who run several accounts that a site's terms allow, such as an agency with a separate account for each client, or a QA team testing different user roles, want each account in its own browser with its own fingerprint.

Rarity matters less than consistency

The usual way to explain fingerprinting is uniqueness: how many other browsers share your exact combination. That matters for tracking. For detection, a second question matters more: do the values agree with each other?

Real devices are internally consistent. A Mac reports macOS fonts, an Apple GPU, a screen size that Apple ships and a timezone that matches the clock. Detection systems have seen billions of real devices and know which combinations occur. When a browser's values contradict each other, the contradiction is a stronger signal than any single rare value. Common contradictions include:

1. A user agent that says Windows next to fonts only a Mac has.
2. A timezone of New York next to an IP address in Frankfurt.
3. A page that reports one set of values while its Web Worker reports another.
4. A canvas image that changes every time it is drawn, which never happens on real hardware.
5. Built-in functions that no longer look built-in, because a script replaced them.

The last three are worth dwelling on, because they are how a fingerprint that was changed by a script on top of the browser gives itself away.

Two ways to change a fingerprint

Tools that give each profile its own fingerprint do it in one of two ways.

A script layered on top. An extension, a launcher or an automation plugin injects JavaScript into each page before the page's own code runs. The script replaces functions such as the one that reports the user agent or reads canvas pixels. It is quick to build, which is why it is common. But the page runs in the same JavaScript world as the script, so it can inspect the script's work: a replaced function prints its own source instead of [native code], a property moves to a different place, a Web Worker or a fresh iframe that the script did not reach still gives the original answer, and the request headers, which the script cannot touch, disagree with what JavaScript reports.

A change in the browser engine. The browser's own source code is changed and rebuilt, so the code that reports the user agent, draws a canvas or lists fonts returns the profile's value directly. Nothing is injected, every scope gets the same answer, and the headers agree with JavaScript because the same code writes both.

Our explainer on engine-level fingerprint protection walks through each observable difference in detail.

How to test your own fingerprint

You can see your own fingerprint, and whether it is consistent, in about a minute.

1. Open our free browser fingerprint test. It runs entirely in your browser and sends nothing anywhere.
2. Read the groups from top to bottom: identity, screen, hardware, graphics, audio, fonts, media devices and automation tells.
3. Look at the consistency checks. Each one compares two things that should agree, such as the user agent and the client hints, the timezone and the clock offset, the page and a Web Worker, or two readings of the canvas taken one after the other.
4. Run it again in a private window. The fingerprint ID will usually be the same, which shows why private browsing alone does not change how a site recognises you.
5. If you use a proxy or VPN, compare the timezone and languages with the country of your IP address.

The test never estimates how rare your fingerprint is; it tells you what a page can read and whether those values agree. For a guided reading of every row, see how to test your browser fingerprint.

How Browz handles fingerprints

Browz gives every profile its own complete browser, with its own cookies, storage and fingerprint, and sets that fingerprint in the browser engine itself, not with a script on top. No script is added to the pages you visit.

Each profile's values are derived together from a real device type and a seed, so its platform, screen, fonts, graphics, voices and languages agree with each other and stay the same from one session to the next. A few choices follow from the consistency principle:

• Text drawn its own way, without random noise. Each profile gets a small, stable change to how text is drawn, so canvas images differ between profiles but stay identical between two readings.
• Real graphics, chosen labels. WebGL and WebGPU draw with your real GPU, and the vendor and renderer names can be automatic, set by you, or left real.
• Time and place follow the proxy. A profile's timezone, languages and geolocation come from its proxy's measured exit, and WebRTC is limited to that exit.
• Headers and JavaScript agree. The user agent and client hints match the browser version the profile really runs.
• Automation does not change the fingerprint. Driving a profile with Playwright, Puppeteer or an AI agent over MCP leaves the device it presents unchanged.

You can see every protection in plain words on the anti-detect page, and choose Auto, Custom or Real per surface on the engines page.

Our own result

We run the same free test against each Browz release and publish the raw output. On 13 November 2026, Browz 0.1.9 on macOS passed 15 of 15 consistency checks, in both a normal window and headless mode, and the same test found no inconsistencies on Windows or Linux. The checks cover the user agent against the platform and client hints, languages, timezone against clock offset and language, screen against window, touch support, graphics and fonts against the operating system, untouched built-in functions, page against Web Worker and iframe, stable readings, automation flags and the plugin list. The result and its JSON are on the anti-detect page, and you can run the same test in any browser you like to compare.

Frequently asked questions