What an antidetect browser is

“Antidetect browser” is the name people search when they want to know how a site tells one program from another. The sources below do not define that product name. The W3C Privacy Working Group note of 25 September 2025 is guidance for specification authors. It is not a glossary of antidetect browsers and it is not a detector. It describes something else: how a site identifies or re-identifies a user, a program, or a device from settings and other observable characteristics. Those characteristics are the subject whenever the conversation turns to a browser that is supposed to look ordinary.

A site does not have to ask for a name. Some of the data is already in an ordinary request. The page can collect another part by running code on the client. The query “antidetect browser” runs into both layers: what the program says about itself, and what can be read while a person looks at the page.

What the server reads from the header

The HTTP User-Agent header is a string the server uses to learn the application, the operating system, the vendor, and the client version. That is MDN’s description, not a sign of a bot. The string names a program. It does not prove who is at the keyboard, and it does not answer whether a visit was a paid click on an ad. This article has no separate facts about click fraud or about who clicks ads and why. It stays with what the browser reports about itself.

Historically the string identified a specific browser too well. Browsers therefore send a reduced set. The platform version and the device model are frozen, and the minor Chrome version numbers are shown as zeros. The server can ask for detail separately, through client hints. Reducing the string does not remove the header. It narrows what the string says by default and leaves a separate channel when the server wants more.

Spoofing or narrowing the string is not the same as disappearing from the log. The server still receives some string. The question is how far that string separates one installation from another. Sample strings for particular browsers on the MDN page are not copied here. They illustrate the format. They are not a list of “suspicious” values.

Passive collection starts with what is already in the request. The same W3C note uses User-Agent as an example of that channel: it usually names the browser, the engine, the version, and the operating system. Reading it does not require code on the page. For an advertiser the claim stays narrow. The header is an observable trait of a program, not a verdict on the visit.

What a fingerprint means

In the W3C note, a browser fingerprint is the ability of a site to identify or re-identify a user, a program, or a device from settings and other observable characteristics. It can link visits inside one session and across sessions. Linking is also possible across different sites when another origin’s cookie policy does not hand over an identifier. Cookies work differently in that comparison: their presence is easier to notice, and they can be deleted. Fingerprint collection often happens without an explicit sign. A typical fingerprint cannot be cleared or reset with the same gesture that wipes browser storage.

Clearing cookies and using a VPN do not stop later linking by fingerprint. The note says this directly. A new address or an empty cookie jar does not erase the set of settings the page can already observe. The note treats complete elimination of fingerprinting, against an interested party and by widely deployed technical measures alone, as implausible. It does not call mitigations a solution. The surface stretches across the program’s capabilities and into other layers, for example differences in TCP connections.

The page does not retell uniqueness figures from other articles. Those figures are not here, and no share of “recognized” visits follows from the W3C text. The note also does not say that a fingerprint equals a bot or equals an invalid click. It does not sort out the difference between click fraud and sklikivanie. A fingerprint is a way to recognize a party again from traits. What an ad platform does with a click, and whether Yandex returns money, does not follow from the definition.

Passive collection and active collection

The same note splits collection into passive and active.

Passive collection reads what is already in the request, without code on the client. That class includes cookies, the set of HTTP headers, the address, and other network data. User-Agent is an example, not the whole list. Passive collection does not require the page to run a script. It is visible to whoever looks at the request itself.

Active collection runs JavaScript or other code on the client. The note says CSS techniques are already catching up with JavaScript. Examples of active collection include window size, enumerating fonts and connected devices, performance timing, sensors, and rendered patterns. Those are illustrations of classes, not a list of fields used to decide a visit. The list does not mean that any font set or any window size by itself closes access.

Active collection is in principle visible on the client: the code runs in the program the person opened. Traits more often leave for the server in a batch. The server combines them out of the page’s sight. The practical difference is this. While a trait sits in a header, whoever reads the request can see it. When the page measures the window, fonts, or sensors and sends a batch, the combination happens on the server, and the page itself may not show that collection.

The surface the W3C describes is wider than one header. It includes the program’s capabilities and neighboring layers, down to TCP differences. Talking about “antidetect” as the replacement of a single User-Agent string no longer matches what the note calls a fingerprint. The string can be reduced. Observable traits remain, and a typical set cannot be reset the way cookies can.

What these sources do not say

Three boundaries belong side by side. Without them the references grow an extra conclusion.

MDN describes the header and why it was reduced. It does not publish a sign of an automated visit, and it does not list strings a site must use to separate a person from a program. A frozen platform version and zeros in Chrome’s minor numbers describe what browsers send. They are not a quality score for traffic.

The W3C note defines recognizability from settings. It does not define an antidetect browser, it is not a detector, and it does not carry over other people’s uniqueness percentages. The statement that widely deployed measures alone make complete elimination of fingerprinting implausible is about an interested party and about the observation surface. It is not a promise that every site will recognize every visit, and it is not a recipe for hiding a program.

The passive and active lists are classes of examples. They do not set a rule that “many fonts means a bot,” and they do not set a rule that “no JavaScript means an honest visit.” Active collection is in principle visible on the client. That is a property of the class, not a guarantee that every person will see a warning.

For an advertising account the text supports a narrow conclusion. A browser leaves observable traits: a reduced User-Agent, the network, and what a page can collect with code. Those traits help recognize a program again. They do not replace a review of the click, they do not name a statute, and they do not say whether a platform will write the visit off. The name “antidetect browser” is not given its own definition in these sources. What is defined are the mechanisms the name is usually pointed at: the client string and a fingerprint from settings.