Short answer: if you are writing tests, use Playwright. If you are scraping a site that blocks you, use Patchright. It is a drop-in replacement for the same API, so the migration is an import change, and it removes three specific detection signals that vanilla Playwright leaks by design.
The comparison is not really "which browser automation library is better". Patchright is Playwright, with the headless tells patched out of the Chromium build. The real question is whether those three patches are enough for your target, and what you do when they are not.
Choose Before You Read
| Your situation | Use |
|---|---|
| Writing end-to-end tests for your own app | Playwright |
| Scraping a site with no WAF | Playwright — Patchright buys you nothing |
| Getting blocked by Cloudflare on a Node.js stack | Patchright |
| Already on playwright-extra and still blocked | Patchright |
| Blocked by Akamai or PerimeterX behavioural scoring | Neither is reliably enough |
| You want the data, not a stealth stack to maintain | See the last section |
The Three Signals Patchright Removes
Vanilla Playwright is not trying to hide. It is a testing tool, and it announces itself in ways that cost nothing in CI and everything in production scraping. Patchright patches the Chromium binary at build time to remove them.
1. The Runtime.enable CDP leak. This is the one that matters most in 2026. Playwright calls Runtime.enable over the Chrome DevTools Protocol to set up its execution-context bookkeeping. That call is observable from inside the page, and Cloudflare's current detection watches for it specifically. Patchright avoids the call and resolves contexts differently, which is why it passes targets that playwright-extra does not.
2. The HeadlessChrome user-agent string in the binary. Not the runtime navigator.userAgent you can override with a launch argument — the string compiled into the Chromium build, which surfaces in places a JavaScript override never reaches.
3. WebDriver capability exposure. navigator.webdriver and its supporting plumbing, removed at the C++ level rather than deleted from the page context after load.
The distinction that makes this work: the patches land before the browser process starts, not in the page. A JavaScript-injection approach has to redefine properties after load, and redefinition is itself detectable — an Object.defineProperty guard can spot a property whose descriptor was rewritten. There is nothing to spot when the property was never compiled in.
Two consequences follow from the same fact: no JS injection overhead at page load, and a TLS fingerprint closer to a real Chrome session.
Patchright vs Playwright: Side by Side
| Playwright | Patchright | |
|---|---|---|
| API | Reference implementation | Identical, drop-in |
| Built for | Testing and automation | Scraping protected targets |
Runtime.enable CDP call |
Made | Avoided |
| Headless UA string in binary | Present | Patched out |
navigator.webdriver |
Exposed | Removed at build time |
| Patch layer | None | Chromium binary, pre-launch |
| Memory per instance | ~200MB | ~200MB, no added overhead |
| Cloudflare BotFight | Blocked | Passes |
| Cloudflare Enterprise / Turnstile | Blocked | Variable by target |
| Akamai Bot Manager v4 | Blocked | Variable by target |
| Behavioural scoring | Not addressed | Not addressed |
| Browser engine | Chromium, Firefox, WebKit | Chromium |
| Maintenance | Microsoft | Small independent team |
Migrating: It Is an Import Change
Patchright mirrors Playwright's API surface, so on a Node.js codebase the move is the import and the install. Your selectors, your page objects, your waits and your context handling all carry over unchanged.
Two things to keep in mind. First, Patchright is Chromium only — if you are running the same suite across Firefox and WebKit, only the Chromium leg moves. Second, the patched Chromium is downloaded and maintained separately from Playwright's own browser cache, so your CI image gets a second browser build to pull and pin.
The practical test for whether the migration was worth it is not a fingerprint site. It is your own target, at your own request rate, over a few hours — a fingerprint check passes long before a rate-limiter stops caring.
What Patchright Does Not Fix
Patchright removes technical fingerprint signals. Every modern WAF also runs behavioural scoring, and none of the three patches touch it.
Behavioural scoring looks at mouse-movement paths, scroll velocity, dwell time before the first click, keystroke cadence, and the timing distribution of your requests. A patched browser that loads a page, reads the DOM in 400ms and leaves has a signature no binary patch addresses. Against Akamai Bot Manager v4 and PerimeterX/HUMAN this is what typically catches Patchright sessions, and it is why its results there are honestly described as variable rather than passing.
It also does not give you proxies. A clean fingerprint from a datacentre IP that has already been flagged is refused at the edge before anything in the browser is evaluated.
So the failure sequence in practice is: vanilla Playwright blocked instantly → Patchright passes → volume goes up → rate-limited → residential proxies added → behavioural scoring catches the timing → and now you are writing a mouse-movement simulator. That last step is where most teams find out stealth is not a library choice.
Patchright vs the Alternatives
If Patchright is not enough, the next moves are sideways, not up.
- Camoufox — a Firefox fork patched at the C++ level, 0% headless detection on standard tests, but 42.49 seconds average bypass time on a Cloudflare challenge. Right for high-value, low-frequency targets; wrong for a daily catalogue crawl.
- playwright-extra — the JS-injection approach Patchright supersedes. Blocked on Cloudflare Enterprise. Do not start new work on it.
- noDriver — lighter (~80–120MB) and drives Chrome over CDP without Playwright at all, but has no behavioural handling and gets blocked quickly by anything scoring it.
The full matrix across all five, including the Python playwright-stealth line, is in our Playwright stealth benchmark. For the anti-bot systems themselves rather than the tools, see bypassing Cloudflare, Akamai and PerimeterX.
When Patching Stops Being the Answer
There is a volume at which this stops being a library decision and becomes a staffing one.
Stealth tools decay. Each anti-bot vendor ships detection updates, each update needs a corresponding patch, and the gap between the two is downtime on whichever data source you were depending on. Maintaining that cycle is a recurring weekly cost that does not appear in any install command.
If what you actually need is competitor prices, stock levels and product data landing in your systems — rather than a stealth stack to keep alive — the honest answer is that the Patchright-vs-Playwright question is the wrong one. ScrapeWise runs the browsers, the proxies and the challenge handling and delivers structured rows. It is a feed, not a toolkit: no plan and no compute units, just a balance you top up and a charge per delivered page from EUR 0.15 per 1,000, with 5 free requests on every new account.
You can also call 36 ready-made scraping API endpoints directly, or see how this feeds competitor price tracking.
So Which Should You Use?
- Playwright — tests, unprotected targets, or any stack where you need Firefox and WebKit too.
- Patchright — a Node.js scraper that Cloudflare is blocking. It is the cheapest upgrade available and costs you one import line.
- Camoufox — Patchright is passing the fingerprint checks and still getting blocked, and the target is worth 42 seconds a page.
- None of them — you want delivered rows on a schedule and would rather not run a stealth stack at all.
Paste a URL your current tool cannot reach
See why teams switch to ScrapeWise. 97% accuracy benchmark, no per-SKU pricing.
97% accuracy on Amazon benchmarks · no credit card · book a 15-min call →
