We Benchmarked 15 Stealth Browser Engines Against Cloudflare. The Browser Wasn't the Problem.

Every stealth browser engine we tested — including one that spoofs its fingerprint natively at the C++/Blink layer, not through a JS patch — got blocked at the exact same rate once a real anti-bot vendor entered the picture. Not "performed slightly worse." Identically blocked, regardless of how clean its fingerprint was. We run 15 of these engines in production and decided to find out, with actual numbers, whether picking the "best" one matters as much as the marketing around them suggests.

Why "passes a free detector" isn't the real test

Free fingerprint checkers like bot.sannysoft.com look for the obvious tells: is navigator.webdriver set, does window.chrome exist, is the plugin list empty. Every stealth engine worth using clears these by now — they're table stakes, not a differentiator. What they don't check is the thing that actually decides whether a real anti-bot vendor lets a request through: where it's coming from. So we ran the same three engines through both tests — the easy one and the one that actually matters.

Round 1: native spoofing vs. JS-patching, on a free detector

Engine	Core tests (webdriver, chrome, plugins, etc.)	WebGL vendor/renderer
ChromiumFish (native fork)	8/8 pass	FAIL — no WebGL context
patchright (JS-patched Chromium)	8/8 pass	FAIL — no WebGL context
camoufox (patched Firefox)	7/8 pass — fails only the Chrome-specific window.chrome check, which a Firefox-based browser will never have	PASS

Near-total tie on the tests that measure stealth. The one real split: both Chromium-based engines fail the WebGL vendor/renderer check — headless Chrome without a GPU has no real WebGL context to report, native spoofing or not — while camoufox's Firefox engine passes it cleanly. That's a genuine, measurable engine-level difference. It's just not the one "native fingerprint spoofing" was supposed to buy us.

Round 2: the same three engines against a live Cloudflare target, no proxy

This is where it gets interesting, and where a single test target would have misled us. We ran all three against two different Cloudflare-protected sites, direct from the cluster's datacenter IP, no proxy.

Engine	nowsecure.nl (public JS-challenge demo)	g2.com (real Bot Management — 403s a plain curl)
ChromiumFish	PASS	403
patchright	PASS	403
camoufox	PASS	403

Every engine cleared the public demo cleanly — real success content rendered, no challenge page. Every engine hard-403'd on the real Bot Management target, at the exact same rate, regardless of which one had the cleaner fingerprint in Round 1.

"Beats Cloudflare" isn't one claim. A lightweight JS-challenge demo and a real Bot Management deployment are entirely different difficulty levels, and a blog post that tests only the easy one and calls it "beating Cloudflare" is measuring the wrong thing. On the target that actually matters, fingerprint quality bought us nothing.

Round 3: does a proxy pool fix it?

We routed ChromiumFish through our own rotating proxy pool and ran it against g2.com six more times. (Only ChromiumFish takes a proxy per-request in our setup; the other two only read it from a fixed environment variable that isn't set on the live services — so this round is ChromiumFish-only, same scope as the rest of this bench.)

Outcome	Attempts
Hard 403 (small block page)	4 / 6
Real G2 homepage content served — under a 403 status	1 / 6
Proxy hop itself failed (connection dropped)	1 / 6

That middle row is worth sitting with: one attempt returned the actual G2 homepage — correct title, real content, no challenge markers — while the HTTP status code still said 403. Real-world scrape results aren't always a clean pass/fail; sometimes the site hands you the content and the block signal at the same time. We're not counting it as a reliable win. Two exit IPs we sampled from the same pool came back as a Netherlands hosting ASN and a Scaleway (France) address flagged hosting: true — still datacenter and cloud infrastructure, not residential. That's the same character of proxy pool a comparable bench found in June, just different providers.

What actually predicts pass or fail at scale

Stack the three rounds and a pattern falls out that has nothing to do with which stealth browser you picked:

1. Fingerprint spoofing is necessary and roughly interchangeable. Native and JS-patched engines tied on every stealth-specific test we ran. Buying a "better" spoofing engine bought us a WebGL checkbox, not a higher pass rate against a real target.
2. IP reputation is the actual gate. The same three engines went from 3/3 passing to 3/3 blocked purely by changing which Cloudflare deployment they hit — no code changed, no engine changed.
3. A datacenter proxy pool doesn't fix #2. Routing through rotating cloud IPs still failed 4-5 times out of 6 against a real Bot Management target, because the exits were still cloud-hosted, not residential.

If you're optimizing a scraping setup, the lever that moves the needle isn't "which stealth browser." It's what's providing the IP. (We tested that claim further with a fourth, architecturally different engine — see 4 stealth browser engines, one real test.)

The honest cost of running 15 engines yourself

We maintain 15 of these because coverage matters and no single engine wins everywhere — but each one is its own maintenance burden. A native fork like ChromiumFish or Cagebase-class alternatives means compiling and re-compiling a Chromium fork against every security patch (hours per build, tens of gigabytes of disk), not just pip install. A JS-patched engine like patchright needs re-patching every time an anti-bot vendor updates its detection script, which is often. None of that maintenance buys a meaningfully higher pass rate against a target that's actually checking IP reputation — which, per Round 2 and 3, is most of them.

The bottom line

Fingerprint spoofing, done natively or via a JS patch, is table stakes — necessary to clear the easy checks, not sufficient to clear a real anti-bot deployment. Across two benches seven weeks apart, the same three engines have tied on every stealth-specific test we've thrown at them, and split only on whether the request came from a clean IP. If a vendor's pitch for "the best stealth browser" doesn't mention where the request is coming from, it's answering the wrong question.

How we did this (and the caveats)

Infra: all three engines run as always-on microservices in our production Kubernetes fleet, each behind the same POST /fetch contract used across all 15 engines. Requests were single and sequential — this is a benchmark, not a load test.

This is a follow-up to an internal bench run 2026-06-22, re-run fresh for this post rather than reusing the old numbers. Two things changed in the seven weeks between benches worth flagging: areyouheadless's specific test route now 502s (the domain itself is up; that one path is dead, so we dropped it), and CreepJS's trust-score panel isn't recoverable from a static HTML snapshot even after a 20-second settle — its results render in a way our fetch-then-serialize approach can't capture, so we dropped it rather than report a number we can't stand behind. Both engines' proxy layer had also been renamed/restructured in the interim; the pool we tested against is the current live equivalent.

The proxy pool sample is small (2 exits checked directly, 6 attempts against one hard target) — enough to see the datacenter/cloud pattern clearly, not enough to characterize the whole pool's behavior precisely.

Only 3 of the fleet's 15 engines were deep-tested here. They were chosen because they represent the two spoofing approaches worth comparing — native-engine and JS-patched — plus a non-Chromium baseline. The other 12 exist for coverage and weren't part of this comparison.

"Real Bot Management target" is one site (g2.com) confirmed to 403 a plain curl — a reasonable proxy for "a site that's actually checking beyond the JS challenge," not a claim about Cloudflare's product line as a whole.

Skip patching 15 engines yourself

Crawlora runs and maintains the stealth browser fleet, proxy rotation, and anti-bot handling behind one API. 2,000 free credits a month, no card required.

See the Web Scraping APISee pricing