[Blog](https://scrapfly.io/blog) / [blocking](https://scrapfly.io/blog/tag/blocking) / [Is Chrome CDP Detectable? CDP vs WebDriver for Browser Automation](https://scrapfly.io/blog/posts/chrome-cdp-stealth-browser-automation-detection-explained) # Is Chrome CDP Detectable? CDP vs WebDriver for Browser Automation by [Ziad Shamndy](https://scrapfly.io/blog/author/ziad) Sep 11, 2026 18 min read [\#blocking](https://scrapfly.io/blog/tag/blocking) [\#cloud-browser](https://scrapfly.io/blog/tag/cloud-browser) [\#playwright](https://scrapfly.io/blog/tag/playwright) [\#puppeteer](https://scrapfly.io/blog/tag/puppeteer) [\#selenium](https://scrapfly.io/blog/tag/selenium) [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained "Share on LinkedIn") [ ](https://x.com/intent/tweet?url=https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained&text=Is%20Chrome%20CDP%20Detectable%3F%20CDP%20vs%20WebDriver%20for%20Browser%20Automation "Share on X") [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained "Share on Facebook") Summarize this article with [ ](https://chat.openai.com/?q=Summarize%20this%20article%20and%20explain%20how%20Scrapfly%20helps%20me%20scrape%20any%20website%20at%20scale%20and%20bypass%20anti-bot%20systems%20for%20my%20use%20case%3A%20https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained) [ ](https://claude.ai/new?q=Summarize%20this%20article%20and%20explain%20how%20Scrapfly%20helps%20me%20scrape%20any%20website%20at%20scale%20and%20bypass%20anti-bot%20systems%20for%20my%20use%20case%3A%20https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained) [ ](https://x.com/i/grok?text=Summarize%20this%20article%20and%20explain%20how%20Scrapfly%20helps%20me%20scrape%20any%20website%20at%20scale%20and%20bypass%20anti-bot%20systems%20for%20my%20use%20case%3A%20https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained) [ ](https://www.perplexity.ai/search/new?q=Summarize%20this%20article%20and%20explain%20how%20Scrapfly%20helps%20me%20scrape%20any%20website%20at%20scale%20and%20bypass%20anti-bot%20systems%20for%20my%20use%20case%3A%20https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained) [ ](https://www.google.com/search?udm=50&aep=11&q=Summarize%20this%20article%20and%20explain%20how%20Scrapfly%20helps%20me%20scrape%20any%20website%20at%20scale%20and%20bypass%20anti-bot%20systems%20for%20my%20use%20case%3A%20https%3A%2F%2Fscrapfly.io%2Fblog%2Fposts%2Fchrome-cdp-stealth-browser-automation-detection-explained) **Browser API**Automate browsers in the cloud with full JavaScript rendering support. [ Learn More ](https://scrapfly.io/products/cloud-browser-api) [ Docs ](https://scrapfly.io/docs/scrape-api/javascript-rendering) Replacing ChromeDriver with a direct CDP WebSocket removes one obvious automation layer. The same session can still fail a CDP detection test, because the browser build, launch mode, runtime domains, and fingerprint all stay observable. CDP controls Chromium, not stealth. The browser build and its environment decide whether a session gets noticed. This guide checks that claim layer by layer, across Playwright, Puppeteer, Selenium, nodriver, Camoufox, and cloud browsers. ## Key Takeaways - Chrome CDP is a control protocol, not a stealth layer. CDP lets software inspect and control Chromium, but CDP does not hide automation by itself. - Websites do not need the external CDP WebSocket to detect automation. Browser visible side effects, launch flags, fingerprint mismatches, and behavior are enough on their own. - Removing ChromeDriver removes one artifact class, not every signal. A direct CDP client can still expose Runtime side effects and fingerprint gaps. - Playwright, Puppeteer, Selenium, and nodriver are controllers. Camoufox and Scrapium are browser builds. Those sit at different layers of the same stack. - A cloud browser is not automatically stealthier by location alone. The gain comes from the patched browser, a coherent profile, proxy routing, and maintenance. **Get web scraping tips in your inbox**Trusted by 100K+ developers and 30K+ enterprises. Unsubscribe anytime. ## Is Chrome CDP Stealth by Default? No. Chrome CDP is an instrumentation protocol for Chromium, not an anti-detection system. The [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/), or CDP, lets a client send commands to Chromium and receive events back. Commands and events group into domains such as Page, Network, Runtime, DOM, Input, and Target. Removing the ChromeDriver binary drops WebDriver-specific artifacts from a session. A direct CDP client can still create page-visible effects when it enables domains such as Runtime, changes launch flags, or injects controller code. Attachment alone is not the same condition as `Runtime.enable`. A detector never needs access to the external CDP WebSocket. Page code can only infer instrumentation from effects exposed inside the browser environment, not from the connection a controller uses to reach Chromium. `control protocol != browser fingerprint != network identity` Testing the browser is faster than reasoning from the controller name. Scrapfly's tool to [test your browser for automation signals](https://scrapfly.io/web-scraping-tools/automation-detector) reports the common browser and framework automation markers for the session that loads the page: `navigator.webdriver`, headless indicators, and runtime overrides. ## How Does Chrome CDP Fit Into the Browser Automation Stack? CDP is one layer between automation code and a Chromium browser. CDP is not the controller library, the browser binary, the hosting environment, or the proxy sitting in front of the connection. A full scraping stack has six layers, from the code a developer writes down to the site that receives the traffic. 1. Automation code, the script or agent logic a developer writes. 2. Controller library, such as Playwright or Selenium. 3. Control protocol, such as CDP or WebDriver. 4. Browser engine and build, such as stock Chromium or Camoufox. 5. Execution host, device profile, and network identity. 6. Target website and its detection system. Each layer does one job. Confusing two layers is where most CDP stealth claims go wrong, since a change at one layer rarely fixes a problem that lives at another. ### Browser controllers: Playwright, Puppeteer, Selenium, and nodriver [Playwright](https://playwright.dev/), [Puppeteer](https://pptr.dev/), [Selenium](https://www.selenium.dev/), and [nodriver](https://github.com/ultrafunkamsterdam/nodriver) all expose developer APIs for navigation, selectors, input, and events. None of these controllers becomes a stealth browser just by controlling one. A controller drives whatever browser sits underneath it, patched or not, and inherits that browser's signals either way. ### Control protocols: CDP, WebDriver, and WebDriver BiDi CDP is Chromium specific instrumentation built for debugging and automation together. WebDriver is the cross browser automation standard that Selenium was originally built around. [WebDriver BiDi](https://www.selenium.dev/documentation/webdriver/bidi/cdp/) is the bidirectional standard Selenium's own documentation names as the eventual replacement for its temporary CDP access. ### Browser builds: stock Chromium, Scrapium, and Camoufox A stock browser is the baseline for this comparison, but the default binary varies by controller. Playwright installs its Chromium build, current Puppeteer downloads Chrome for Testing, and Selenium or nodriver usually drive an installed browser. Scrapium is a patched Chromium build that stays CDP-compatible while changing what the browser reveals about itself. [Camoufox](https://camoufox.com/) is a patched Firefox build, not a Chromium fork. Camoufox matters here because Camoufox proves stealth and CDP are separate questions, covered later in this guide. ### Execution location: local Chrome and remote cloud browsers A controller can run on a developer laptop while the browser itself runs in a separate process, a container, or a remote cloud environment. Location changes operations and network origin. Location alone does not guarantee stealth, since the browser build under that connection stays whatever it already was. text```text automation code -> controller (Playwright, Puppeteer, Selenium, nodriver) -> control protocol (CDP, WebDriver, WebDriver BiDi) -> browser build (stock Chromium, Scrapium, Camoufox) -> execution host and network (local machine, remote cloud browser) -> target website and detection system ``` Each arrow above is a layer a CDP stealth claim has to survive. A patch or setting applied at one layer rarely changes what the next layer down actually reveals. ## What Can Websites Detect in Chrome CDP Automation? Websites infer CDP automation from effects visible inside the browser itself, then combine those effects with headless, fingerprint, network, and behavioral signals. A page never reads the external CDP WebSocket directly. Detection works by observing what an active CDP session changes inside the page environment the browser already exposes. Five failure modes cover most of what shows up in practice: - **Runtime serialization side effects.** A CDP framework that enables Runtime or Console events can trigger object serialization a page can observe. - **WebDriver state and launch flags.** `navigator.webdriver` and Chromium automation flags are separate from CDP but often show up alongside it. - **Browser fingerprint contradictions.** Canvas, WebGL, fonts, codecs, locale, screen, TLS, and HTTP/2 can disagree with the device a session claims to be. - **Framework and injected-script traces.** Page-level variables or patched native functions can expose the controller or the patch meant to hide it. - **Behavioral repetition.** Identical timing and input patterns add risk even when every static property on the page passes. ### CDP Runtime.enable and object serialization [Brotector](https://github.com/ttlns/brotector) calls its check `runtime.enabled`. The current test uses two error-preview hooks: an own `Error.stack` getter and a separate getter on `Error.prototype.name`. Two V8 changes in May 2025, [preventing object-preview side effects](https://chromium.googlesource.com/v8/v8/+/61a907540d4c1dda4733476e54c977910f31041d) and [guarding error previews](https://chromium.googlesource.com/v8/v8/+/e08e97347454255a337dcea361808fb25ca09077), retired the classic own-stack getter. In a Chrome 152 control run, Brotector recorded `stackLookupCount:0` but `nameLookupCount:3` with `Runtime.enable`; attachment without that domain produced no detection. The surviving signal is therefore a Runtime-enabled error-preview side effect through Brotector's prototype-name path, not proof that the old stack getter still works or that a page can read the external WebSocket. An August 2024 [r/webscraping report](https://www.reddit.com/r/webscraping/comments/1evht3i/help_in_bypassing_cdp_detection/) captures the maintenance risk of the older technique. The author found advice to disable `Runtime.enable` but no implementation that worked in that setup, then worried that freezing Error objects to suppress the getter could break page functionality. ### navigator.webdriver and Chrome launch flags Keep this signal separate from CDP itself. WebDriver active state and Chromium automation launch flags often coexist with a CDP session, but neither one is the protocol. Current Chrome exposes `navigator.webdriver` as a Boolean: an ordinary session returns false, while `--enable-automation`, `--headless`, or `--remote-debugging-port=0` makes it true. A CDP attachment alone does not set it, but the launch configuration can. Overriding the value to `undefined` does not match normal Chrome and can leave a detectable descriptor change. ### Chromium fingerprint and behavior mismatches Canvas, WebGL, audio, fonts, locale, and screen settings all feed a fingerprint independent of CDP. A separate guide on [how browser fingerprinting works](https://scrapfly.io/blog/posts/how-browser-fingerprinting-works) covers each vector in depth. One [Stack Overflow report](https://stackoverflow.com/questions/79582148) from April 2025 described a related tradeoff. Switching to Playwright fixed a 50 tab reliability problem, but BrowserScan then flagged the session for CDP. Treat that report as one setup, not a benchmark across frameworks. ## How Do CDP and WebDriver Detection Differ? WebDriver and CDP expose different control paths, so each protocol removes some artifacts and introduces others. Neither protocol is a stealth guarantee on its own. | Dimension | WebDriver | Chrome CDP | Stealth implication | |---|---|---|---| | Primary scope | Cross-browser automation standard | Chromium instrumentation | Browser coverage, not stealth | | Typical controller | Selenium | Puppeteer, nodriver, Playwright's Chromium connection | Controller may add its own traces | | Separate driver | Common with ChromeDriver | Not required for a direct CDP client | Removes one artifact class | | Page-visible signals | WebDriver state, driver variables, launch flags | Runtime serialization and controller side effects | Different detection surface | | Browser fingerprint | Still observable | Still observable | Protocol choice does not fix it | | Network and behavior | Still observable | Still observable | Handled at a different layer | Selenium's own position is more nuanced than WebDriver only. Selenium's architecture is WebDriver first, and Selenium exposes selected Chrome and Edge CDP commands temporarily while WebDriver BiDi support matures. Direct CDP access still has value outside stealth work. Lower level Chromium control, network interception, and performance data are all reasons to reach for CDP even when detection is not the concern. ## How Do Playwright, Puppeteer, Selenium, and nodriver Use CDP? These four tools provide different developer APIs and connection paths, but a target site ultimately evaluates the browser and traffic it receives, not the library name. | Tool | Layer | Primary path for Chromium | Browser supplied by default | What it does not guarantee | |---|---|---|---|---| | Playwright | Controller framework | Launch a managed browser, or attach with `connectOverCDP` | Bundled Chromium, Firefox, or WebKit | Stealth | | Puppeteer | Controller library | High-level API over the browser's control protocol | Supported Chrome or Firefox | Stealth | | Selenium | Controller framework | WebDriver, plus selected Chromium CDP access | Installed browser and driver setup | Stealth | | nodriver | Direct Python controller | CDP without ChromeDriver or Selenium | Installed Chromium-based browser | Undetectability | ### Playwright and Puppeteer with Chromium CDP Playwright and Puppeteer both hide raw CDP commands behind page-level APIs such as clicks, selectors, and waits. Neither library exposes JSON commands directly in everyday use. Playwright's own documentation warns that [connectOverCDP](https://playwright.dev/docs/api/class-browsertype#browser-type-connect-over-cdp) only supports Chromium-based browsers and produces a connection with lower fidelity than Playwright's own protocol connection. Puppeteer's [supported browsers](https://pptr.dev/supported-browsers) page currently lists Chrome and Firefox. Puppeteer's Firefox support does not run over CDP the same way its Chromium support does. ### Selenium with WebDriver and temporary CDP access Selenium stays WebDriver first, and Selenium can send selected Chrome and Edge CDP commands on top of that base connection. Existing Selenium code does not attach natively to an arbitrary remote CDP WebSocket the way Playwright's `connectOverCDP` does. ### nodriver without ChromeDriver or Selenium nodriver's own documentation states its architecture plainly. There is no ChromeDriver binary and no Selenium dependency, with direct access to CDP domains, methods, and events. Removing ChromeDriver lowers one detection surface, the artifacts that binary itself introduces. Removing ChromeDriver does not harden every browser fingerprint or network signal by itself, a distinction the FAQ returns to later. ## Why Can Camoufox Be Stealthy Without Chrome CDP? Camoufox can be stealthy without CDP because Camoufox modifies Firefox itself. CDP is a Chromium protocol, so CDP plays no part in Camoufox's control path. Camoufox is an open-source anti-detect Firefox build with a Playwright-style Python interface. Its current README warns that it may not suit stable production use, and its 2026 stealth page reports fingerprint inconsistencies after a maintenance gap. Treat it as an engine-level architecture option that still requires target-specific validation. Interface and engine are not the same thing. A Playwright-shaped `click()` call does not mean the browser underneath is Chromium, and it does not mean CDP is involved. Three projects mentioned in this guide make that split visible: - Camoufox: a patched Firefox build plus a high-level controller. - nodriver: direct CDP access plus stock Chromium. - Scrapium: a patched Chromium build that keeps remote CDP compatibility. The useful question is never which method a controller calls. The useful question is where fingerprint consistency actually gets enforced, inside the engine or bolted on top of it. Scrapfly #### Need to bypass anti-bot protection? Scrapfly's Unblocker handles Cloudflare, DataDome, and more — automatically. [Try Free →](https://scrapfly.io/register)## Does a Remote Cloud Browser Make Chrome CDP Stealthier? Not by location alone. A stock Chromium container running in the cloud can expose the same browser-level signals as stock Chromium running on a developer's own machine. What actually changes when a browser moves off a local machine is process location, browser fleet ownership, network egress, proxy routing, session persistence, and who maintains browser versions and patches. ### Local stock Chromium over CDP Controller and browser can run on the same machine here. The target site sees the browser build and the network identity it connects from, not where the source file sits on disk. ### Remote stock Chromium over CDP Moving that same unmodified browser to a server changes infrastructure and often IP reputation. Moving it does not automatically repair runtime, fingerprint, or behavior signals the browser was already leaking. ### Scrapium over a remote CDP WebSocket Developer code connects Playwright or Puppeteer to [Scrapfly Cloud Browser API](https://scrapfly.io/products/cloud-browser-api), which runs Scrapium remotely and hands back a signed CDP WebSocket URL. Attribute the stealth work here to the patched Chromium build, a coherent device profile, proxy and locale alignment, and ongoing maintenance. None of that stealth work comes from CDP itself, which stays the same connection method either way. [Playwright Cloud Browser integration](https://scrapfly.io/docs/cloud-browser-api/playwright) documents `connect_over_cdp` for Chromium specifically. Selenium stays WebDriver-first and does not attach to that same remote CDP WebSocket the way a Chromium-based Playwright connection does. python```python import asyncio import os from playwright.async_api import async_playwright TARGET_URL = "https://web-scraping.dev" async def local_browser(): async with async_playwright() as pw: browser = await pw.chromium.launch() page = await browser.new_page() await page.goto(TARGET_URL) print("local Chromium title:", await page.title()) await browser.close() async def remote_browser(): api_key = os.environ["SCRAPFLY_API_KEY"] browser_ws = ( f"wss://browser.scrapfly.io?api_key={api_key}" "&proxy_pool=public_datacenter_pool&os=windows" ) async with async_playwright() as pw: browser = await pw.chromium.connect_over_cdp(browser_ws) context = browser.contexts[0] page = context.pages[0] if context.pages else await context.new_page() await page.goto(TARGET_URL) print("remote Scrapium title:", await page.title()) await browser.close() asyncio.run(local_browser()) asyncio.run(remote_browser()) ``` The local path requires Playwright's Chromium binary; the remote path also requires `SCRAPFLY_API_KEY`. Once configured, both functions load the same target through the same page API, while launch versus CDP connection selects the browser and network environment. | | Local stock Chromium | Remote stock Chromium | Remote patched Chromium | |---|---|---|---| | Browser build | Unmodified Chromium | Unmodified Chromium | Scrapium, patched Chromium | | Controller location | Same machine as browser | Separate from browser | Separate from browser | | Network identity | Developer or office IP | Server or datacenter IP | Proxy-routed, locale-aligned IP | | Profile coherence | Whatever the OS reports | Whatever the container reports | Aligned device profile | | Fleet maintenance | Manual, by the developer | Manual, by the developer | Managed by the provider | | Stealth implication | Depends on local hardening | Remote location alone adds no browser hardening | Provider maintains browser and profile hardening | The matrix makes the source of the benefit explicit. The patched browser and its coherent environment do the work, not the remote connection by itself. ## How Do Browser Patches Reduce Chrome CDP Detection? The deeper a patch reaches into the browser, the more signal families it can keep coherent. No patch at any depth creates permanent undetectability. Three levels of patching show up in practice, from shallowest to deepest: 1. JavaScript property overrides and stealth plugins, applied after the browser launches. 2. Patched controller or browser distributions, such as Patchright or a documented [Playwright stealth setup](https://scrapfly.io/blog/posts/playwright-stealth-bypass-bot-detection). 3. Engine-level browser builds, such as Camoufox and Scrapium. Shallow patches carry their own risk. Overridden native functions, altered prototypes, and values that disagree with the rendering or network layer can create a new, more specific inconsistency than the one they patched over. The same Reddit developer cited earlier worried that an Error-stack patch could break real page functionality once shipped. Treat that worry as evidence of ongoing maintenance risk, not proof that every shallow patch fails in production. A guide to [best stealth browsers](https://scrapfly.io/blog/posts/best-stealth-browsers) covers selection criteria across these three levels in more depth than fits here. ## How Should You Test Chrome CDP Automation for Detection? Test the complete session, not just `navigator.webdriver`, and treat every public scanner as one bounded probe rather than a final verdict. A useful test sequence runs four layers in order: 1. Automation markers: WebDriver state, CDP side effects, headless traces, and framework fingerprints. 2. Browser fingerprint coherence: Canvas, WebGL, AudioContext, fonts, locale, and screen settings. 3. Network coherence: IP type, geography, timezone, TLS, HTTP/2, and WebRTC leaks. 4. Target behavior: challenge rate, CAPTCHA frequency, session continuity, and failures across repeated runs. Compare the same controller logic across a local stock browser and the candidate hardened setup. Keep the target, the action sequence, and the network conditions controlled wherever that is possible. The automation detection tool covered earlier is a reasonable first diagnostic for the browser-marker layer. The fingerprinting guide linked earlier covers layer two in more depth. Passing a public scanner does not prove a setup will pass a specific production target. Cloudflare, DataDome, and similar systems run their own signals that no public scanner fully reproduces. ## When Should You Use CDP, WebDriver, or a Cloud Browser? Choose the control path for capability and maintenance first. Evaluate stealth as its own separate requirement once the control path is settled. | Reader job | Starting point | Why | Main limit | |---|---|---|---| | Cross-browser testing | Selenium with WebDriver or WebDriver BiDi | Standards-based browser coverage | Driver and browser artifacts remain | | Chromium automation with a high-level API | Playwright or Puppeteer | Productive selectors, waits, events, and debugging | Stock browser is not stealth | | Low-level Chromium control without ChromeDriver | nodriver or another direct CDP client | Direct access to CDP domains | CDP and fingerprint signals remain | | Firefox-based anti-detect evaluation | Camoufox | Engine-level patches and a Playwright-style API | Current fingerprint inconsistencies; test the exact release | | Remote, maintained Chromium execution | Cloud Browser with a patched browser | Outsources fleet, profile, proxy, and session work | Service cost and provider dependency | Scrapfly Cloud Browser fits the last row specifically. Remote CDP control over a maintained, patched Chromium instance replaces a browser fleet a team would otherwise run itself. For a reader who needs rendered data rather than browser-level control, a higher-level [Web Scraping API](https://scrapfly.io/products/web-scraping-api) can be simpler than driving CDP directly. ## FAQ Does Playwright always use CDP?No. Playwright supports Chromium, Firefox, and WebKit through its own automation stack, and `connectOverCDP` is a Chromium-only attachment method. Playwright's documentation also warns that CDP attachment carries lower fidelity than a native Playwright protocol connection. Can CDP control Firefox or Camoufox?No. Chrome DevTools Protocol targets Chromium based browsers specifically. Camoufox is Firefox based and exposes a Playwright-style interface without turning Firefox into a CDP controlled browser. Is nodriver undetectable?No. nodriver removes the ChromeDriver binary and the Selenium dependency, but the underlying Chromium session can still expose CDP side effects, fingerprint inconsistencies, network identity, and automated behavior patterns. Does headed Chrome hide CDP automation?Not by itself. Headed mode removes some older headless-only differences, but headed mode does not erase CDP instrumentation, controller traces, fingerprint mismatches, or behavioral signals a target might check. ## Choosing a Chrome CDP Stealth Setup CDP decides how software controls Chromium. The browser build, profile coherence, network identity, behavior, and ongoing maintenance decide how detectable that controlled session actually is. A rough escalation path holds up across most projects. Start with a stock controller and browser for ordinary automation. Add a maintained stealth browser once fingerprinting starts mattering. Move to a managed cloud browser once remote execution and fleet upkeep become the real cost. Testing a Scrapfly Cloud Browser session through the same Playwright code path, then checking its browser markers with the automation detection tool, is a fast way to see this layer model hold up on a real session. Legal Disclaimer and PrecautionsThis tutorial covers popular web scraping techniques for education. Interacting with public servers requires diligence and respect: - Do not scrape at rates that could damage the website. - Do not scrape data that's not available publicly. - Do not store PII of EU citizens protected by GDPR. - Do not repurpose *entire* public datasets which can be illegal in some countries. Scrapfly does not offer legal advice but these are good general rules to follow. For more you should consult a lawyer. [ Add as a preferred source ](https://google.com/preferences/source?q=scrapfly.io) Table of Contents Table of Contents- [Key Takeaways](#key-takeaways) - [Is Chrome CDP Stealth by Default?](#is-chrome-cdp-stealth-by-default) - [How Does Chrome CDP Fit Into the Browser Automation Stack?](#how-does-chrome-cdp-fit-into-the-browser-automation-stack) - [Browser controllers: Playwright, Puppeteer, Selenium, and nodriver](#browser-controllers-playwright-puppeteer-selenium-and-nodriver) - [Control protocols: CDP, WebDriver, and WebDriver BiDi](#control-protocols-cdp-webdriver-and-webdriver-bidi) - [Browser builds: stock Chromium, Scrapium, and Camoufox](#browser-builds-stock-chromium-scrapium-and-camoufox) - [Execution location: local Chrome and remote cloud browsers](#execution-location-local-chrome-and-remote-cloud-browsers) - [What Can Websites Detect in Chrome CDP Automation?](#what-can-websites-detect-in-chrome-cdp-automation) - [CDP Runtime.enable and object serialization](#cdp-runtime-enable-and-object-serialization) - [navigator.webdriver and Chrome launch flags](#navigator-webdriver-and-chrome-launch-flags) - [Chromium fingerprint and behavior mismatches](#chromium-fingerprint-and-behavior-mismatches) - [How Do CDP and WebDriver Detection Differ?](#how-do-cdp-and-webdriver-detection-differ) - [How Do Playwright, Puppeteer, Selenium, and nodriver Use CDP?](#how-do-playwright-puppeteer-selenium-and-nodriver-use-cdp) - [Playwright and Puppeteer with Chromium CDP](#playwright-and-puppeteer-with-chromium-cdp) - [Selenium with WebDriver and temporary CDP access](#selenium-with-webdriver-and-temporary-cdp-access) - [nodriver without ChromeDriver or Selenium](#nodriver-without-chromedriver-or-selenium) - [Why Can Camoufox Be Stealthy Without Chrome CDP?](#why-can-camoufox-be-stealthy-without-chrome-cdp) - [Does a Remote Cloud Browser Make Chrome CDP Stealthier?](#does-a-remote-cloud-browser-make-chrome-cdp-stealthier) - [Local stock Chromium over CDP](#local-stock-chromium-over-cdp) - [Remote stock Chromium over CDP](#remote-stock-chromium-over-cdp) - [Scrapium over a remote CDP WebSocket](#scrapium-over-a-remote-cdp-websocket) - [How Do Browser Patches Reduce Chrome CDP Detection?](#how-do-browser-patches-reduce-chrome-cdp-detection) - [How Should You Test Chrome CDP Automation for Detection?](#how-should-you-test-chrome-cdp-automation-for-detection) - [When Should You Use CDP, WebDriver, or a Cloud Browser?](#when-should-you-use-cdp-webdriver-or-a-cloud-browser) - [FAQ](#faq) - [Choosing a Chrome CDP Stealth Setup](#choosing-a-chrome-cdp-stealth-setup) Join the Newsletter Get monthly web scraping insights Scale Your Web Scraping Anti-bot bypass, browser rendering, and rotating proxies, all in one API. Start with 1,000 free credits. No credit card required 1,000 free API credits Anti-bot bypass included [Start Free](https://scrapfly.io/register) [View Docs](https://scrapfly.io/docs/onboarding) Not ready? Get our newsletter instead. ## Related Articles [ nodejs headless-browser ### How to Web Scrape with Puppeteer and NodeJS in 2026 Introduction to using Puppeteer in Nodejs for web scraping dynamic web pages and web apps. Tips and tricks, best practic... ](https://scrapfly.io/blog/posts/web-scraping-with-puppeteer-and-nodejs) [ blocking nodejs ### Puppeteer Stealth: Complete Guide to Avoiding Detection Complete guide to puppeteer-extra-plugin-stealth for avoiding bot detection. Learn how detection works, configure stealt... ](https://scrapfly.io/blog/posts/puppeteer-stealth-complete-guide) [ python nodejs ### How to use Headless Chrome Extensions for Web Scraping In this article, we'll explore different useful Chrome extensions for web scraping. We'll also explain how to install Ch... ](https://scrapfly.io/blog/posts/how-to-use-browser-extensions-with-playwright-puppeteer-and-selenium) ## Related Questions - [ Q Getting started with Puppeteer Stealth ](https://scrapfly.io/blog/answers/how-to-use-puppeteer-stealth-what-does-it-do) Bypass anti-bot protection automatically, **1,000 free credits** [Start Free](https://scrapfly.io/register)