Browser Leaks Test: Fingerprint, Antidetect and Bot Checks

Automation: 6 checks

Fingerprint consistency: 20 checks

• What the browser claims: the user agent against the Client Hints platform, against the Client Hints version and against navigator.platform; the claimed browser against its JavaScript engine; the claimed version against the features that engine really has.
• What the device claims: the operating system against the WebGL GPU (Direct3D on a Mac user agent), against the installed fonts and against the speech voices; plausible CPU cores and device memory; touch support against the device type; the screen size against media queries and the window.
• Values in other contexts: the main page against a Web Worker and against an iframe; native browser functions patched by a script.
• Noise: in canvas, WebGL pixels, the audio fingerprint and client rects.
• Locale: the time zone against the date offset; the languages against the locale and the Accept-Language header.

Network and IP: 14 checks

• The IP: a datacenter IP, a VPN network, a Tor exit.
• Headers: proxy headers such as Via and X-Forwarded-For.
• Location fit: the browser time zone against the IP's, the languages against the IP's country.
• Leaks: WebRTC, the DNS resolver against the IP, an IPv6 address from another network than the IPv4 one.
• The connection: the TCP/IP operating system against the browser's, a tunnel MTU, the latency gap, the TLS client against the claimed browser, the system clock against the server's time.

Ten of these are also the checks of the IP checker; the latency gap, the TLS client, the IPv6 network and the clock run only here.

A site does not need to know your fingerprint to flag it. It looks for values that cannot be true together. Direct3D exists only on Windows, so a profile that claims macOS while WebGL names Direct3D contradicts itself, and so does one with Windows fonts or Windows speech voices. So does a user agent that claims a newer Chrome than the engine's features show, or Client Hints that name another platform than the user agent.

Spoofing leaves seams. A script or extension that changes navigator values on the page often misses the copies a Web Worker or a fresh iframe reads, and a patched function stops looking native when a script inspects it. The test reads the values in all three places and checks the functions.

Noise can be measured. To give each profile its own canvas, WebGL and audio hashes, many antidetect browsers add small random changes to what those APIs return. A script can draw the same thing twice, or draw something whose result is known, and look for differences a real graphics card or audio stack does not make. Noise that changes on every read is easier to catch than noise that stays the same for the profile.

Uniqueness is another question. AmIUnique and the EFF's Cover Your Tracks measure how rare your fingerprint is among their visitors. A rare but consistent fingerprint is still a real device; a common but contradictory one is a spoof. This test scores consistency, and no browser is undetectable: the aim is a profile with nothing that contradicts itself.

Most fixes are profile settings, not proxy settings. AdsPower, GoLogin, Dolphin Anty, Multilogin, Incogniton and BitBrowser name them differently, and labels can differ slightly between versions.

Then compare fingerprint IDs: two profiles that show the same ID share their stable values, and a site that fingerprints can tie them together. Setup guides for each app: AdsPower, GoLogin, Dolphin Anty, Multilogin, Incogniton and BitBrowser, with an overview in antidetect browsers.

A browser under automation shows itself in ways a person's browser does not:

• The WebDriver flag. Selenium and other WebDriver tools make navigator.webdriver return true, as the W3C standard requires.
• The DevTools protocol. Puppeteer and Playwright drive Chrome over the DevTools protocol, and ChromeDriver uses it under Selenium; a page script can notice the connection. An open DevTools window uses it too, so the check can fail while you debug in a normal browser.
• Headless defaults. Headless Chrome names itself HeadlessChrome in the user agent unless you change it, and older headless builds have no PDF viewer plugins, an outer window of 0 by 0 and no window.chrome.
• No graphics card. On a server, WebGL runs in software, and the renderer reads SwiftShader or llvmpipe.

If you automate a browser for testing or for collecting public data, these checks show what a site's bot detection sees. A headed browser on a machine with a real GPU, a lasting user profile and no automation flags leaves fewer traces; stealth plugins patch only the traces they know, and they fall behind new checks. Follow each site's terms. Guides: Selenium, Puppeteer, Playwright and browser fingerprinting in web scraping.

The proxy decides the IP, its network and type, and the traits of the TCP connection that reaches the site. The rest stays with your browser and your machine.

• TLS client. The handshake that starts an HTTPS connection, summed up as JA4 or JA3, depends on the software that opens it, and real Chrome, Firefox and Safari each have their own. A proxy tunnels the handshake unchanged, so a script that sends a Chrome user agent through a proxy still shows a script's handshake. More: TLS and TCP fingerprinting.
• TCP/IP and MTU. Through a proxy, the TCP connection that reaches the server is the proxy side's, so its operating system can contradict your browser's; through a VPN the packets are your own, but the tunnel lowers the MTU.
• Latency gap. The server times the TCP connection's own round trip and the round trip a page script measures. With a proxy in the path, the TCP round trip ends at the proxy while the script's runs all the way to you, so the second is much longer.
• IPv6 from another network. If your browser reaches the server over IPv6 from your own provider while the IPv4 address is the proxy's or VPN's, part of your traffic goes around it.
• System clock. A clock far from the server's time points to a paused virtual machine or a date set by hand; it can fail without any proxy.

Each test reads its own set of values, uses its own rules and turns them into its own verdict, so one profile can pass one test and fail another.

• Different checks. A value one test reads, another ignores, and two tests can read the same value and judge it differently.
• Different reference data. What is normal for a given Chrome version changes with each release, and tests update their rules on their own schedules.
• Different IP data. The IP type and location come from each test's own database.
• Timing. Checks that time the connection, or gather WebRTC addresses, can differ between two runs.
• A test is not a site. Anti-fraud systems also weigh your account, cookies, behavior and history, and they do not publish their rules.

When tests disagree, read the reason each one gives. A contradiction that one test names is there for any site that looks for it.

Below the checks, collapsible tables list the raw values a site can read: navigator and user agent, Client Hints, hardware (CPU cores, memory, touch, GPU), screen and window, time zone and languages, the canvas hash, the WebGL vendor and renderer with a hash of its parameters, the audio hash, detected fonts, media devices and speech voices, codecs, permissions, storage and privacy flags (cookies, Do Not Track, Global Privacy Control), the TLS fingerprint (JA4, JA3 hash, TLS version, ALPN), the TCP/IP fingerprint (TTL, window, MSS, options) and the WebRTC IPs. Copy report puts them on your clipboard as JSON, so you can compare two profiles side by side.