What is browser fingerprinting?

Browser fingerprinting is the practice of recognizing a browser from the details it exposes to websites, such as its user agent, screen, time zone, languages and the way it draws graphics. The W3C describes it as a site's capability "to identify or re-identify a visiting user, user agent, or device" (Mitigating Browser Fingerprinting in Web Specifications). Unlike a cookie, a fingerprint isn't stored on your device, so clearing your browser data doesn't reset it.

Websites use fingerprints for fraud prevention, bot detection, account security and advertising. This guide explains the main signals, how they are read, why a consistent fingerprint matters more than a rare one, and how to test your own browser.

Passive and active fingerprinting

The W3C guidance separates two kinds:

• Passive fingerprinting uses what the browser sends anyway, in every request: the IP address, the User-Agent header, the Accept-Language header, client hint headers and similar details. The site needs no script, and you can't see it happen.
• Active fingerprinting runs JavaScript in the page to measure more: draw an image and read back the pixels, process an audio signal, list the WebGL renderer, read the screen size and time zone. The guidance notes that active fingerprinting is "potentially detectable on the client", because the code runs in your browser.

How unique is a fingerprint?

The best-known early study is Peter Eckersley's How Unique Is Your Web Browser? (EFF, 2010). Of 470,161 browsers that visited the test site, 83.6% had a fingerprint that was unique in the sample, and the fingerprint distribution carried at least 18.1 bits of entropy. That study predates canvas and audio fingerprinting.

Those techniques appeared in the wild soon after. Englehardt and Narayanan's 1-million-site measurement (an extended version of their ACM CCS 2016 paper) found canvas fingerprinting on 14,371 sites (1.6% of the top million), canvas-based font fingerprinting on 3,250 first-party sites, AudioContext fingerprinting scripts, and WebRTC used to discover local IP addresses on 715 sites. These numbers are from 2016 and have certainly changed, but they show that every signal below has been used in practice.

The signals

User agent and client hints

The user agent string names the browser, its version and the operating system. Chrome has reduced it over several releases: the User-Agent Reduction plan freezes the minor version to 0.0.0 and the platform part to fixed strings such as Windows NT 10.0; Win64; x64 or Macintosh; Intel Mac OS X 10_15_7, whatever the real system version is.

The detail that left the string moved to User-Agent Client Hints. Every page can read the low-entropy values (brand list, mobile flag and platform). A script can request high-entropy values with getHighEntropyValues(): platform version, architecture, bitness, device model and the full version list. On Windows, the platform version is the only way to tell Windows 11 from Windows 10: Microsoft documents that values of 13.0.0 and above mean Windows 11 (Microsoft Learn). Client hints are a Chromium feature; MDN marks them as not available in some widely used browsers, and Safari and Firefox don't expose them.

For fingerprinting, the user agent and the client hints are less interesting on their own than together. They should name the same operating system and the same major version.

Canvas

A script draws text and shapes on an HTML <canvas>, reads the result with toDataURL() or getImageData(), and hashes it. The same drawing produces slightly different pixels on different systems. Mowery and Shacham, who first described the technique in Pixel Perfect: Fingerprinting Canvas in HTML5 (W2SP 2012), found that the operating system, browser version, graphics card, installed fonts, subpixel hinting and anti-aliasing all play a part.

A related method uses measureText(), which returns the width of a string in a given font. By measuring the same text in many fonts, a script can tell which fonts are installed. Englehardt and Narayanan's detection rule for this was a script that sets at least 50 distinct fonts and calls measureText at least 50 times on the same string.

WebGL

WebGL exposes the graphics stack in two ways. The WEBGL_debug_renderer_info extension returns the vendor and renderer strings of the graphics driver, which often name the exact GPU. A script can also render a 3D scene and hash the pixels, as with canvas. Firefox disables the extension when its privacy.resistFingerprinting setting is on.

Audio

Audio fingerprinting processes a generated signal, usually from an OscillatorNode inside an OfflineAudioContext, and hashes the output. Small differences in the audio processing stack produce different results. No sound plays and no microphone is used.

Fonts

The set of installed fonts differs between machines, especially once design software or language packs are installed. Scripts detect fonts by measuring text, as described above, or by comparing the size of page elements rendered with a fallback font.

Screen and hardware

screen.width and screen.height, the available area, color depth and devicePixelRatio describe the display. navigator.hardwareConcurrency reports logical CPU cores, and navigator.deviceMemory reports memory, rounded to a power of two and clamped between bounds to protect owners of unusual devices.

Time zone and language

Intl.DateTimeFormat().resolvedOptions() returns the time zone and the locale used for formatting (MDN). navigator.languages lists the user's preferred languages, which are also sent in the Accept-Language header. On their own these are common values. Compared with the IP address's location, they become a consistency check.

WebRTC

WebRTC lets browsers connect directly for calls and file transfer. To find a route, the browser gathers ICE candidates, including a public address learned from a STUN server ("server reflexive", or srflx, in MDN's terms). A page can trigger this without a call and without a permission prompt. If the browser uses a proxy for web traffic but not for WebRTC, the STUN answer can contain the real IP address. That is a WebRTC leak.

Local network addresses used to appear too. Modern browsers replace them with random mDNS names ending in .local, an approach described in the IETF draft Using Multicast DNS to protect privacy when exposing ICE candidates. RFC 8828 sets out four IP handling modes, from exposing every interface to forcing all WebRTC traffic through the proxy.

Automation flag

navigator.webdriver is true when the browser is controlled by automation, for example when Chrome is started with --enable-automation or --headless. It exists so that automated sessions can identify themselves, and sites use it to treat automated traffic differently.

Why consistency matters more than uniqueness

Real browsers are internally consistent. A Windows laptop in Paris usually reports a Windows user agent and Windows client hints, the Europe/Paris time zone, French or English languages, a graphics card that exists on Windows laptops, and a canvas image that doesn't change between two reads.

Fingerprint changes that break these relationships stand out. The FP-Scanner study (USENIX Security 2018) compared the operating system claimed in the user agent with navigator.platform, the WebGL renderer, fonts and media queries, and examined canvas images for signs of added noise: missing transparent pixels, isolated stray pixels, and near-matches where an exact color was expected. It detected the countermeasures the authors tested from the inconsistencies they introduced. The authors noted that being detected with a countermeasure can make a browser more trackable, though not always.

Typical inconsistencies are:

• The time zone is in a different offset from the IP address's location.
• None of the browser languages fits the IP's country, or the formatting locale differs from the first language.
• WebRTC reveals a public IP that differs from the IP the site sees.
• The user agent says Windows while the client hints say macOS, or the versions differ.
• The canvas hash changes on every read, or a flat-colored square comes back with altered pixels.
• measureText() returns impossible widths because masking broke it.
• The window is wider than the reported screen.

How browsers defend against fingerprinting

Browser vendors take two broad approaches.

Make everyone look the same. Tor Browser standardizes many values so its users blend together. EFF's Cover Your Tracks calls Tor Browser "the most realistic protection" against fingerprinting. Firefox's resistFingerprinting setting follows a similar idea.

Make each site see something different. Brave adds small random changes to canvas, WebGL and audio output so that each site and each session sees a different fingerprint (Brave, 2020). The aim is to stop sites from linking the same browser across sites and sessions.

Chrome's user agent reduction removes detail from the passive fingerprint, and the W3C guidance asks spec authors to weigh fingerprinting surface in every new API.

None of these approaches is designed for running separate work accounts. They aim to stop tracking across sites, not to give each of your profiles a stable, distinct identity.

How to test your own browser

You can check the most common signals with our free tools. Each runs in your browser, and none stores results.

• Browser fingerprint test: compares your time zone, languages, formatting locale, WebRTC address, user agent platform and automation flag with the IP address the site sees.
• WebRTC leak test: shows the public address WebRTC reveals and any local addresses, and compares them with your connection IP.
• Canvas fingerprint test: draws a test image, hashes it, checks whether the result is stable and whether text measuring works.
• User agent checker: shows the user agent string next to the client hints, including high-entropy values.
• Proxy checker: shows the IP, location, time zone and network that websites see for your connection.

For a uniqueness estimate against a large visitor pool, Cover Your Tracks from the EFF compares your browser with recent visitors and also tests tracker blocking.

How Multime handles fingerprinting

Multime runs each profile as its own Chromium-based browser built on fingerprint-chromium, an open-source Chromium build with fingerprint patches. Its approach is consistency per profile, not randomness per page:

• Seed per profile. A seed drives the masked values, so a profile looks the same every time it opens and two profiles never share values. You can switch a profile to a new fingerprint on every start.
• Noise where it helps. Canvas, WebGL image, audio and element sizes (ClientRects) get masking from the seed. Graphics card info can be masked or real, and CPU cores come from the seed or a custom number.
• Locale from the proxy. Multime checks the IP through the proxy and sets time zone, language and geolocation to match. It keeps the page language list consistent with the browser's interface language.
• WebRTC choices. Through proxy, replace IP, disabled, or real.
• Identity. You choose the operating system shown to websites and the browser brand (Chrome, Edge, Opera or Vivaldi). The user agent is set automatically to match the engine.

Some values are not masked, and we say so. Screen size is always the real screen. Media devices, speech voices and custom font lists are not masked. On the Windows engine (Chrome 150), canvas masking is switched off automatically because that build breaks text measuring when it is on, which is exactly the kind of inconsistency described above. In our own test on 22 October 2026 on macOS with the Chrome 152 engine, Pixelscan reported a Multime profile as consistent, with "No masking detected" and "No automated behavior detected". That is one tool on one date, not a guarantee.

Sources

• W3C, Mitigating Browser Fingerprinting in Web Specifications, Group Note.
• Peter Eckersley, How Unique Is Your Web Browser?, EFF, 2010.
• Keaton Mowery and Hovav Shacham, Pixel Perfect: Fingerprinting Canvas in HTML5, W2SP 2012.
• Steven Englehardt and Arvind Narayanan, Online Tracking: A 1-million-site Measurement and Analysis, extended version of the ACM CCS 2016 paper.
• Antoine Vastel et al., FP-Scanner, USENIX Security 2018.
• Pierre Laperdrix et al., Browser Fingerprinting: A Survey, ACM Transactions on the Web.
• WICG, User-Agent Client Hints; Chromium, User-Agent Reduction.
• IETF, RFC 8828: WebRTC IP Address Handling Requirements.
• MDN Web Docs pages linked in each section above.