Chrome DevTools Protocol (CDP)

The Chrome DevTools Protocol is the JSON-over-WebSocket interface that Chromium exposes for instrumenting and controlling a browser from outside it. It is organized into domains that map to what the DevTools panels do: Page for navigation and lifecycle events, Network for request interception and header and cookie control, Runtime for evaluating JavaScript in a page context, DOM for querying and mutating the document tree, and Input for synthesizing mouse and keyboard events. Chrome's own DevTools UI is a CDP client, which is the clearest way to understand it: anything you can do by hand in DevTools, a program can do over the same channel.

Essentially every browser-infrastructure product sits on top of this. Puppeteer is a thin wrapper over CDP, Playwright drives Chromium through it, and Selenium 4 added CDP access alongside WebDriver. That matters commercially because CDP is a remote protocol: a client can attach to a browser running on another machine by connecting to a WebSocket endpoint. That remote attachment is what the cloud-browser business is built on. When Browserbase, Steel.dev, Browserless, or any other cloud-browser vendor sells you a session, what you receive is a CDP endpoint URL, and your existing Puppeteer or Playwright code connects to it with a one-line change instead of launching a local Chrome. The vendor's actual value is everything wrapped around that endpoint: warm browser pools so a session starts in hundreds of milliseconds rather than seconds, session persistence and reuse, proxy egress, fingerprint management, live view and replay, and autoscaling. The protocol itself is free and open; the managed browser behind it is what you pay for.

For a buyer, the useful consequence is portability. Because every serious vendor speaks the same protocol, migrating between cloud-browser providers is mostly a configuration change rather than a rewrite, and the same is true of moving from a local browser to a hosted one. Lock-in, where it exists, comes from the higher-level SDK layered on top, such as Stagehand's natural-language actions, rather than from the transport. Ask any vendor whether raw CDP is exposed or only their own abstraction, since that answer determines your exit cost.

The complication is that CDP use is itself detectable, so the same channel that drives the browser can give the automation away. DataDome's Antoine Vastel published the best-known technique in June 2024: enabling the Runtime domain causes Chromium's inspector to serialize objects passed to console methods, so a page can log an object with a getter on it and observe whether the getter fires. Rebrowser, whose product is patched Chromium, documents Runtime.enable as a command that always leads to detection and flags Page.setBypassCSP and Emulation.setUserAgentOverride as further tells, and maintains rebrowser-patches, an open-source set of drop-in patches for Puppeteer and Playwright that avoids the Runtime.enable leak. The point for a decision-maker is that the choice of automation library is not neutral on block rates, and any vendor claiming stealth should be able to say specifically which CDP side effects they neutralize.