What can a browser bot-detection test tell you?

Public bot-detection checks read the browser in front of them and report what looks unusual: automation markers, headless hints, browser APIs that behave unlike a native implementation, identity values that contradict each other, graphics that do not match the claimed device, or values that change between one read and the next. They do not see the server-side request fingerprint, the behavior history, or the account record, so their output is a description of a browser, not a decision about an account.

Which free checkers show bot-detection signals?

Two cautions before comparing any of them. First, a tool that shows a bot row and a tool that reports an automation finding inside a broader assessment are answering at different resolutions; neither is automatically more correct. Second, scores from different tools are not interchangeable, because the inputs, weights and pass/fail thresholds are not public in the same way. Compare the specific findings, not the headline numbers.

For a wider look at this tool family, our free fingerprint checker comparison covers six tools — EnvTrace, BrowserLeaks, Pixelscan, BrowserScan, IPhey and CreepJS — in more depth, including what each one exposes beyond the bot question. Note that the set differs from the table above: that page profiles BrowserLeaks and IPhey, and does not cover APIVoid.

What can a browser bot-detection test observe?

A public check can report signals the page was able to read during that run:

• Automation markers. Properties and globals that automation frameworks typically leave behind, such as a webdriver flag, headless browser hints in the user agent, or empty language lists.
• API behavior. Whether selected browser interfaces still behave like native implementations, whether navigator properties carry unusual overrides, and whether similar information read through different interfaces disagrees.
• Identity conflicts. User agent, platform, Client Hints and device claims that do not describe the same device.
• Graphics and hardware. WebGL vendor and renderer, CPU thread count, device memory or screen values that do not fit the claimed device class.
• Cross-context differences. Values that agree on the main page but differ inside an iframe or a Web Worker.
• Stability. Signals that change between repeated reads within the same session.

Some tools also look at the network. A public IP address, WebRTC-exposed addresses or DNS behavior are observations about the network path. They are not, by themselves, proof that a browser is automated.

How should you read an automation finding?

Treat an automation indicator as a finding to inspect, not as a probability that a service will block an account. Read the specific signal and its context.

A browser used intentionally for Playwright or continuous integration should be understood as a test environment, not as a problem to hide. A headless hint in a profile that is supposed to be a normal desktop browser is worth investigating. The same finding means different things depending on what the environment is for.

Then check how the tool reached the result. EnvTrace does not reduce its output to a single pass or fail, and neither should your reading of it:

• A finding means a signal was read and looked unusual. EnvTrace grades the evidence behind a finding rather than flattening it — from a strong conflict, through strong evidence, to a signal that merely needs review.
• An observation is recorded but does not necessarily reduce the score. A changed value between two tests, for example, is usually an observation, because browser updates and profile changes move those values too.
• Unknown means the signal could not be read at all. This is the state people skip.

Missing or unreadable data is not the same as a passing check, and a clean result is not a guarantee either, because another service may use information a public browser test cannot see. Read the named findings and the coverage figure together rather than one number alone. A single API anomaly also does not determine that an entire profile is compromised; it is one piece of evidence among several.

How do automation signals fit into EnvTrace’s five dimensions?

EnvTrace reports automation-related evidence inside API Integrity, the dimension that asks whether the browser interfaces visible to the page behave consistently with the rest of the environment. That dimension covers automation indicators, overridden navigator properties, non-native behavior, and clear differences between interfaces that should agree.

The other four dimensions answer adjacent questions:

• Identity consistency — do user agent, platform, Client Hints and device claims describe one device?
• Graphics and hardware — do WebGL, memory, core count and screen values fit that device?
• Cross-context consistency — do the main page, an iframe and a Worker agree?
• Stability — do repeated reads return the same result?

Two things follow from that design. Automation is evaluated together with other evidence rather than scored in isolation, so one odd property does not produce a dramatic verdict on its own. And every dimension carries a coverage figure: checks that lacked enough data stay unknown instead of being counted as passed. The published methodology documents how dimensions, evidence levels and coverage work.

This is a browser-side fingerprint assessment. It is not a verdict that a browser is a bot, and it is not a platform-approval score.

A practical sequence for checking a profile

1. Run the test in the exact browser profile or authorized test environment you want to understand. Note whether automation is intentionally in use.
2. Read the API Integrity findings before the overall score. Separate a signal that conflicts with another value from one the test could not read.
3. Check identity consistency: user agent, platform and Client Hints should describe the same device.
4. Check graphics and hardware against that claimed device class.
5. Compare cross-context results — main page, iframe, Worker.
6. Re-read for stability; unexplained changes within one session are worth a second run.
7. If the network path matters, check public IP, WebRTC and DNS as separate tests and interpret them as network observations.
8. For authorized debugging, identify the source of a confirmed finding, change one known configuration at a time, and retest in the same environment.

Use the results for QA, compatibility or privacy review, not to bypass another service’s controls.

What can’t a public test tell you?

A public browser test cannot predict a third-party service’s decision. A service may combine server-side request and network-protocol signals, behavior, account and login history, device history, correlations across visits, and private detection rules.

That is why a page that reports “no automation found” and a platform that restricts an account can both be accurate at the same time. The browser result describes one layer. The platform decision is made on layers a public test cannot reach.