Detection · 2026-08-20

How antidetect browsers get detected

Not by a blocklist. By values that do not agree with each other — and most of those are configuration, not product.

Reading this rating. Scores are computed from published vendor figures read on 2026-08-20, not from private measurement. We do not rate detection resistance, because it cannot be measured honestly from outside — see method.

Detection is about contradiction, not recognition

The intuitive model — a site keeps a list of antidetect browsers and blocks them — is mostly wrong. Anti-bot systems rarely need to identify a product. They look for a profile that does not hold together.

01Values that disagree
A user agent claiming macOS with a Windows font list. A German IP with a US timezone. A mobile screen size with desktop hardware hints. Each is cheap to check and expensive to fake consistently.
02Spoofing artefacts
Overridden properties can behave differently from native ones under unusual queries. This is an arms race: vendors close gaps, detection finds new ones, neither side publishes.
03Implausible rarity
A fingerprint unique among millions is itself a signal. Blending in beats hiding, which is why chasing a zero uniqueness score is the wrong goal.
04Implausible commonness
The opposite failure: thousands of sessions sharing one identical fingerprint because a default preset was never changed.
05Everything outside the browser
Account age, payment method, address, phone number, behaviour. Most account linking happens here, and no browser touches any of it.

Why we do not score this

A rating that claimed to measure detection resistance would need to test each product against each major platform, repeatedly, over time, with controlled proxies and matched account histories — and then publish results that go stale within weeks and that no reader could reproduce.

Nobody does this. Sites that publish detection rankings are inferring them from marketing copy, from forum anecdotes, or from nothing. We would rather leave the column empty and explain the mechanics, which is at least durable.

What you can control

Failure modes, ranked by how often they are the actual cause · checked 2026-08-20
Failure	Where it comes from	Visible in a checker	Fixable by you
WebRTC leak	Configuration	Yes	Yes
Locale contradicts proxy geo	Configuration	Yes	Yes
Reused payment or address	Operations	No	Yes
Default preset shared across profiles	Configuration	Partly	Yes
Poor proxy quality	Supplier	Partly	Yes
Behavioural patterns	Operations	No	Partly
Spoofing artefact in the product	Vendor	No	No

The last row is the only one that is the browser's fault, and it is the one people spend the most time choosing between products over.

Questions

Can websites detect an antidetect browser?

Yes, in principle. Anti-bot systems look for contradictions between reported values and observable behaviour, and for artefacts of the spoofing itself. Whether a given site does detect one depends on how much it invests in the problem.

How is an antidetect browser detected?

Usually not by recognising the product. It is by inconsistency — values that do not agree with each other, properties that behave differently from a genuine browser under stress, or a fingerprint that is implausibly rare or implausibly common.

Does a more expensive antidetect browser get detected less?

There is no published evidence either way, and we are not going to invent it. Price correlates with team features and support far more reliably than with anything measurable about detection.

What is the most common mistake?

Contradiction between proxy geography and browser locale, and WebRTC announcing a real address. Both are configuration errors rather than product failures, and both are visible in any fingerprint checker before a platform ever sees them.