Patchright vs Playwright: What Patchright Actually Patches (2026)

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 specific detection signals that vanilla Playwright leaks by design.

The comparison is not really "which browser automation library is better". Patchright is Playwright, with its automation leaks patched out of the driver. The real question is whether those patches are enough for your target, and what you do when they are not.

Choose Before You Read

What Patchright Changes

Vanilla Playwright is not trying to hide. It is a testing tool, and it announces itself in ways that cost nothing in CI and a lot in production scraping. Patchright patches the Playwright driver to remove the main ones. Per its README (checked Nov 2026):

1. The Runtime.enable CDP leak. Playwright calls Runtime.enable over the Chrome DevTools Protocol to track execution contexts, and that call can be detected from inside the page. Patchright avoids it by running its JavaScript in isolated execution contexts. The README calls this "the biggest patch", and it is the main reason Patchright gets further than playwright-extra, which works in JavaScript and cannot remove a CDP call.

2. Console.enable. Also detectable, so Patchright disables the Console API. The side effect is that console output does not work in Patchright.

3. Launch flags. It adds --disable-blink-features=AutomationControlled, so navigator.webdriver is not set, and drops --enable-automation and several other Playwright defaults such as --disable-extensions.

The distinction that makes this work: these changes happen in the driver and at launch, not in the page. A JavaScript-injection approach has to redefine properties after load, and redefinition is itself detectable, because an Object.defineProperty guard can spot a property whose descriptor was rewritten. A property that was never set leaves nothing to spot.

What Patchright does not touch is the browser binary. The TLS handshake comes from whichever Chromium or Chrome you launch, which is one reason the README recommends real Google Chrome over Chromium.

Patchright vs Playwright: Side by Side

Facts from each project's documentation and the npm registry, checked Nov 2026.

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, npx patchright install chromium (or patchright install chrome for the recommended real Chrome) is its own install step, so your CI image needs it added. The README's fullest setup is also headed, with a persistent context and no fixed viewport, which on a server means a virtual display.

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 automation signals. Modern bot-management products also run behavioural scoring, and none of the 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 pattern no driver patch addresses. Against vendors that weight behaviour heavily, such as Akamai Bot Manager and HUMAN (PerimeterX), that is the layer left to catch you, so do not expect a driver patch alone to settle it.

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 usual failure sequence 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 with fingerprint changes made at the C++ level. Its own README puts memory at about 200MB per browser and warns that performance has dropped with the current Firefox base (checked Nov 2026). Right for high-value, low-frequency targets; heavy for a daily catalogue crawl.
• playwright-extra: the JavaScript-injection approach Patchright supersedes. Its last npm release, 4.3.6, was in March 2023 (checked Nov 2026). Do not start new work on it.
• nodriver: drives real Chrome over CDP without Playwright or WebDriver at all. Python only, AGPL-3.0 licensed, and no behavioural handling.
• No browser at all: on Akamai, which reads the TLS handshake before anything in the page, TLS impersonation with curl_cffi fixes the first signal checked and runs without a browser, at a fraction of the compute. The Akamai-specific argument is in Playwright vs Akamai Bot Manager.

A wider comparison, including the Python playwright-stealth line, is in Playwright stealth in 2026. For install commands, language and browser coverage and the limits in one place, see What Is Patchright? 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 Patchright-vs-Playwright question is the wrong one. ScrapeWise (which publishes this blog) runs the browsers and the proxies and delivers structured rows as a table, CSV or Excel, through the API or over MCP. You pay per page: EUR 0.15, 0.75, 1.50 or 3.75 per 1,000 pages depending on whether the page needs rendering or residential proxies. Schedules run at most once a day, plus manual runs. Some sites block automated visits or need a login, and no tool covers every site.

You can also call 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 or Python scraper that is being blocked on browser signals. 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 a heavier, slower browser per page.
• None of them — you want delivered rows on a schedule and would rather not run a stealth stack at all.

If it is that last one, the import line you change is ours rather than Patchright's:

pip install scrapewise

from scrapewise import ScrapewiseClient

with ScrapewiseClient() as sw:          # reads SCRAPEWISE_API_KEY from the environment
    html = sw.load_site("https://www.example.com/product/123")

load_site returns the page's HTML through our proxy pool, so the patch-and-detection cycle in this article is ours to keep up with, not yours. Run your own target URLs through it: the first 5 requests are free, no card needed, then the per-page rates. If you would rather stay in the editor, the same key works as an MCP server.