We surveyed the stealth browser industry by using our bot detection framework to analyse 11 of the top hosted browser services.

This post first appeared on botforensics.com.

Brightdata's Browser API ranked highest. In our test, the only significant weakness of Brightdata's service was that its DigitalOcean hosting was detectable. It otherwise presents as a completely plausible human user. It was also unique by being the only service not to present Linux TCP characteristics. Most of the services work around the TCP fingerprinting problem by browsing with a Linux User-Agent. Others spoof a non-Linux platform but still give away their Linux nature.

We are not paid by any of the companies in this survey. Some have given us trial credit, but that did not affect the measurements reported here.

Results

Ranked by number of rule hits, less is more stealthy.

Methodology

Our collector page combines server-side detections (e.g. HTTP headers, TCP characteristics) with information extracted from inside the browser context via JavaScript.

Many of the companies running these browsers are startups who are still moving very fast, and we have seen their stealth browser behaviours change from week to week.

To make a fair point-in-time comparison, we fetched our collector page from each of these services on the same day (23rd of April 2026).

Where a service offers more than one way to use their browser, we started by picking the one that was either selected by default, or presented most prominently. For expedience, we favoured using the browser in an online playground where available rather than writing an integration to use it via the API. We did not have the browser interact with the web page by clicking buttons, filling forms, or following links: we just navigated to the page and waited for it to finish loading. (Except in the case of Browser-Use, but see Appendix, and this did not impact the result).

Please see the Appendix for a specific description of how we used each tool, along with other comments on each service.

The table is ranked according to the number of distinct detection rules triggered during a session, where less is better. This is useful as a ranking signal, but no 1-dimensional ranking can cover a multi-dimensional preference space, YMMV.

Where we have detected (for example) "Browserless", "Browser-Use", or "Steel" in the "Automations detected" column, this is from a specific rule in our detection platform. Of course we know for every row of the table which bot the fetch came from (because we initiated it), but in some cases we detect them automatically.

Conclusion

All 11 of the tested hosted browser services were detectable, with Brightdata being the stealthiest. The common weak points were:

• a non-Linux claimed OS but with Linux TCP characteristics
• leaking information about the hosting environment
• unexpected JavaScript code being injected into the page
• unexpected JavaScript code running inside the page context

We may be able to help if you:

• run a hosted browser service that is missing from this survey and you would like to be in the next one, or
• run one of the services in this table and would like to know how we detect you, or
• run your own headless browser and want to make sure it looks human

Please get in touch, we'd love to help.

Appendix

Brightdata

Appears to lack an interactive playground.

I used their "Browser API" with default configuration, using a hand-written JavaScript client via their Playwright integration.

Kernel

It has an onboarding flow that gives you example commands and lets you run them from inside the browser, but it doesn't give you the opportunity to edit the URL.

I used the Python/CDP example code from my PC locally, using the kernel pip module.

ZenRows

I'm pretty sure ZenRows used to have a live demo on their home page, which I have used in the past, but it is gone now. Once you sign up for an account there is an opportunity to type in a URL, which I used. The default selection was that the results would be delivered "As Markdown". In this configuration it resulted in only a single GET / fetch, so I changed it to "As Screenshot" which caused a full headless browser fetch.

Hyperbrowser

I loaded up the "Hacker News Stories" TypeScript example in the playground, and edited the code to make it fetch our collector page. I looked in the configuration and it had "Stealth mode" activated by default, and OS set to Linux.

Browserless

I used the "Enter a URL to test our unblocker..." form on the home page. Brownie points to Browserless because they let you try it without making you sign up first.

Browserbase

I used the example "Visit Hacker News" script from their playground, and edited it to fetch our collector page.

Surprisingly, after fetching the collector page, Browserbase caused a fetch for the collector page's favicon from inside my local browser context!

This means that if you use the Browserbase playground then it will potentially leak your real life IP address and browser information to the page you are trying to look at, which is maybe not what a user would expect.

OpenWebNinja

OpenWebNinja has a lot of different services available. I used the "Web Unblocker API" inside the playground, and edited the default config to make it fetch our collector page.

Uniquely, this service did 4 different fetches of the URL we gave it, which I suppose gives it 4x as many chances to evade bot detection, pretty good idea.

Browser-Use

I used the agent chat interface:

Can you please browse to [URL] and tell me what you can see?

This only triggered a single GET / request. It initially refused to do any more on the site because it thought our collector page was a phishing site. I told it that it is my site and it shouldn't worry about it, which it accepted.

To provoke it to do a full browser session I asked it to dismiss the cookie modal. I manually excluded any rule hits triggered by the dismissal of the cookie modal so as not to unfairly disadvantage Browser-Use.

Steel

I used the steel CLI tool with steel scrape [URL].

This worked, in the sense that I could see that it caused a headless browser session that fetched our collector page, but the CLI tool eventually exited with a 500 error instead of giving any results. But we still saw the browser session so it was good enough for the survey purposes.

Spider

In "Quick Start" I used the "Unblocker" endpoint with the "curl" example, which only caused a single GET / request.

So then I tried out "Cloud browser sessions over websocket" mode and manually typed in our collector page URL in the playground.

Strangely, fetches within the same browser session came from different IP addresses and even countries, though all in Europe.

Anchor

I used their "AI form filling" example but edited the prompt to:

Can you please browse to [URL] and tell me what you can see?

And this worked.