Patchright vs Rebrowser-Patches: Stealth Playwright Patches Compared 2026

If you’re choosing between Patchright and rebrowser-patches for stealth Playwright automation in 2026, the decision comes down to how much control you want over the patching layer and how much maintenance burden you can absorb. Both projects patch Playwright’s Chromium binaries to remove the fingerprints that bot-detection services like Cloudflare, DataDome, and PerimeterX key on — but they take fundamentally different architectural approaches, and those differences matter at scale.

What Each Project Actually Does

Patchright is a drop-in fork of Playwright that ships pre-patched binaries. You install it, import it like Playwright, and get stealth behaviors out of the box: navigator.webdriver removed, consistent chrome.runtime objects, patched Runtime.enable CDP leak, and more. The repo is actively maintained and tracks Playwright releases within a few days of upstream. As of mid-2026 it sits at Playwright parity around the 1.44-1.46 range.

rebrowser-patches is a different beast. It’s a patch set (not a fork) you apply yourself against Playwright or Puppeteer source. The headline fix is the Runtime.enable CDP leak — the single most reliable bot-detection signal in 2025-2026. When Playwright calls Runtime.enable globally to support page.evaluate(), it sets a detectable flag inside V8. rebrowser-patches reroutes this to per-execution-context calls so the global flag never fires.

This distinction matters: rebrowser-patches is surgical. Patchright is comprehensive but opinionated.

Feature and Architecture Comparison

For teams running Python scrapers, Patchright is almost always the right pick. For Node.js pipelines where you need surgical control over exactly which CDP calls are exposed, rebrowser-patches gives you more precision.

The Runtime.enable Problem in Detail

This is worth understanding concretely. Standard Playwright opens a CDP session and calls Runtime.enable once for the entire page lifecycle. Detection services check Runtime.executionContextCreated event timing and the internal __nightmare / automation flags that this global enable leaks.

rebrowser-patches rewires Playwright’s internal evaluate path so every page.evaluate() or page.waitForFunction() call spins up its own execution context, runs, then tears down. the global Runtime.enable never happens.

Here’s what the patched behavior looks like from a DevTools protocol trace:

# Without patch - one global Runtime.enable at page load
CDP: Runtime.enable (global)
CDP: Runtime.executionContextCreated { id: 1, ... }

# With rebrowser-patches - per-call contexts
CDP: Runtime.enable (context-scoped)
CDP: Runtime.evaluate { contextId: 42 }
CDP: Runtime.disable

Patchright handles this too, but bundles it with a full binary patch. If you’re using Patchright and also want to read the full stealth picture, the Playwright Stealth: Anti-Detection Setup for 2026 guide covers the complete fingerprint surface beyond just CDP.

Setup and Maintenance Reality

Patchright setup is three lines:

from patchright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=False)
    page = browser.new_page()
    page.goto("https://example.com")

That’s it. The binary ships patched. No build toolchain, no npm rebuild steps, no checking whether the patch still applies cleanly after a Playwright version bump.

rebrowser-patches requires you to:

1. Clone the Playwright repo at a specific tag
2. Apply the patch with git apply
3. Run npm install and npm run build (this takes 5-15 minutes)
4. Point your project at the local build
5. Repeat on every Playwright version update you need

For a solo scraping project, that’s manageable. For a team running CI pipelines, it’s a real overhead. Some teams mitigate this by pinning Playwright versions and only updating quarterly — which creates its own fingerprint drift problem as browser versions age.

If you’re evaluating managed cloud browsers that handle this patching at the infrastructure level, the Browserless vs Browserbase vs Steel.dev: Cloud Browser Showdown 2026 breakdown is worth reading before committing to self-managed stealth.

Detection Bypass Effectiveness

In practice, both projects pass the standard creepjs and sannysoft fingerprint test pages. The meaningful difference shows up against more aggressive detectors:

• Cloudflare Bot Management (not just the free JS challenge): rebrowser-patches’ granular CDP fix has a marginal edge because it more closely mimics a real Chrome DevTools-free session. Patchright passes most Cloudflare targets but has occasional failures on high-security endpoints.
• DataDome: Both perform similarly. Residential proxy quality matters more here than the stealth patch. Pairing either with proper proxy DNS handling (see Proxifier SOCKS v5: How to Force Proxy DNS Resolution (2026)) eliminates a common leak vector.
• PerimeterX / HUMAN: Canvas and WebGL fingerprint consistency matters more than CDP here. Patchright’s broader patch surface gives it an edge.

One thing that doesn’t show up in test pages but matters in production: Patchright ships a patched chrome.runtime that makes the browser look like a real Chrome extension environment. Sites that check typeof chrome.runtime.connect get a real-looking response rather than undefined. rebrowser-patches doesn’t touch this.

For context on how stealth browsers compare more broadly, the undetected-chromedriver vs nodriver vs Patchright: Stealth Browser 2026 article covers the Python ecosystem specifically.

If your workflow involves any keyboard-driven browser automation or thin scraping wrappers built on browser extensions, Surfing Keys, Vimium, Tridactyl: Keyboard Browser Automation for Scraping documents an underused technique that pairs well with either stealth approach.

Bottom Line

For most teams, Patchright wins on pragmatism: lower setup cost, Python support, and a broad patch surface that covers more than just CDP. Use rebrowser-patches if you’re on Node.js, need surgical control over CDP behavior, or are building a patching pipeline you’ll maintain yourself. Both projects are production-viable in 2026 — the choice is really about your stack and how much you want to own. DRT will keep tracking both as bot-detection arms races continue to evolve.

Related guides on dataresearchtools.com

• Browserless vs Browserbase vs Steel.dev: Cloud Browser Showdown 2026
• Surfing Keys, Vimium, Tridactyl: Keyboard Browser Automation for Scraping
• undetected-chromedriver vs nodriver vs Patchright: Stealth Browser 2026
• Proxifier SOCKS v5: How to Force Proxy DNS Resolution (2026)
• Pillar: Playwright Stealth: Anti-Detection Setup for 2026