WebDriver BiDi is the W3C standard that lets Puppeteer and others automate Chrome and Firefox. What it changes for bot detection, and what stays visible.
For years, "automating Chrome" and "speaking the Chrome DevTools Protocol" were nearly the same thing. That is changing: WebDriver BiDi is a W3C-standard protocol that gives automation tools the same kind of live, event-driven control, in more than one browser. For anyone who detects automation, and for anyone whose CI sessions get flagged, the question is what happens to the signals that were tied to the old channel. This guide explains what BiDi is, which detection signals it weakens, and which ones it leaves untouched.
Key Takeaways
- WebDriver BiDi is a standard, bidirectional protocol. It runs over a WebSocket, lets the browser push events to the automation client, and is specified by the W3C Browser Testing and Tools Working Group. The specification is still a Working Draft.
- It was built to replace the "CDP for everything" habit. CDP is tied to Chrome DevTools and is not a shared public standard, so BiDi combines WebDriver Classic's cross-browser standardisation with CDP-style low-level, event-driven control.
- One signal class weakens. Detection that keys on side effects of CDP itself, such as the
Runtime.enablebehaviour covered in our CDP automation detection guide, may observe nothing when the same script drives the browser over BiDi. - Most of the stack does not care about the protocol.
navigator.webdriver, headless rendering differences, behavioural timing and network-layer fingerprints describe the browser and its traffic, not the wire format the automation client used. - The right response is layered scoring, not a single tell. Defenders should treat "CDP side effect present" as one input that will fire less often over time.
What WebDriver BiDi Is
WebDriver has two generations. WebDriver Classic is the request-and-response protocol Selenium grew up on: the client sends a command, the browser answers, and the client has to poll for anything that happens in between. The Chrome DevTools Protocol (CDP) is the opposite trade: fast, bidirectional and low-level, but designed for Chrome's own DevTools and not a shared public standard.
The WebDriver BiDi specification aims to take the good parts of both. In the words of the Chrome team's introduction to the protocol, it is a new standard automation protocol meant to combine the best of WebDriver Classic and CDP: bidirectional messaging, low-level control, and a W3C standard behind it. Bidirectional means the browser can push events, such as a console message, a network request or a navigation, to the client the moment they happen, instead of waiting to be asked.
The same post is explicit that BiDi is not simply CDP with a new name. CDP contains Chrome- and DevTools-specific parts that cannot be copied into a cross-browser spec, and BiDi has to keep round trips low because client and browser may not sit on the same machine. That design pressure is why BiDi's commands and events look different from CDP's, and it matters for detection because the observable side effects differ too.
Where It Stands in Adoption
Adoption is tracked by the tools' own announcements, so it is worth quoting dates rather than guessing a roadmap. The Chrome team's post on production-ready WebDriver BiDi states that Firefox 129 and Puppeteer 23 each got production-ready support, with Puppeteer offering stable Firefox automation through BiDi from version 23 and its CDP support remaining unchanged.
Before that, Puppeteer's Firefox support relied on Mozilla implementing and maintaining a subset of CDP inside Firefox, which the post describes as a stopgap that could never guarantee the full Puppeteer API. BiDi replaces that arrangement with a shared standard. The practical reading: Firefox automation moved to BiDi first, while Chromium automation through Puppeteer still commonly uses CDP. "Replacing CDP" is a direction of travel, not a completed switch. Check the current release notes of your own framework before assuming which protocol a given session used.
What Changes for Detection
The detection-relevant point is narrow and worth stating precisely. Techniques that infer "a CDP client is attached" from what CDP does inside the renderer, the sort of side channel described in our CDP detection guide, depend on a CDP domain being enabled. If a script drives the browser over BiDi, those particular effects may simply not occur. A detector that leaned on that one check will see fewer positives, not because the traffic became human but because the control channel changed.
Two cautions keep this honest. First, BiDi implementations are new, and how any specific framework or browser build configures a session is an implementation detail that can change between versions; treat claims about a particular tool as things to verify against its documentation. Second, a browser can be driven over several protocols at once, and some frameworks still use CDP alongside BiDi for features BiDi does not yet cover, so a session is not automatically CDP-free just because BiDi is in use.
What Stays Detectable Regardless of Protocol
The protocol is only the wire between the automation client and the browser. Everything that describes the browser itself and how it behaves is unaffected.
| Signal | Why the protocol does not change it |
|---|---|
navigator.webdriver | The WebDriver specifications define a "webdriver-active" state for a browser under remote control, and BiDi's session handling sets and clears it. Whether the flag is exposed in a given session is a browser and framework matter, so verify it rather than assume. |
| Headless rendering tells | Software-rendered graphics, missing plugins and window-size defaults come from how the browser is launched. See headless browser detection. |
| Behavioural timing | Perfectly regular input timing and missing pointer movement are properties of the script. See behavioural bot detection. |
| Network-layer fingerprints | TLS and HTTP/2 fingerprints come from the browser's network stack and the IP's reputation, not from the control channel. |
This is why a mature detection stack scores many weak signals together. Losing one class is expected; the bot detection techniques survey shows the rest of that stack.
If You Run Automation and Get Flagged
Test engineers and monitoring teams often meet detection from the wrong side: a legitimate CI job gets a challenge page. Switching protocols is not the fix, and it is not what this article recommends. The useful steps are boring ones. Run your own suite against sites you control or have permission to test, allowlist your CI's IP ranges with the site owner, and use the vendor-approved route where one exists: services that welcome automated traffic often provide a way for clients to identify themselves, such as an API or signed requests, which is far more reliable than trying to look human. Our piece on AI agent traffic covers how the line between "bot" and "software acting for a person" is being redrawn.
To see what your own browser session exposes, open the bot detection tool: it lists which automation flags the current session raises, and it is the same class of checks a real detection stack combines.
Frequently Asked Questions
Is WebDriver BiDi replacing CDP?
Not entirely, and not everywhere yet. BiDi is a standard designed to give cross-browser automation the event-driven control that used to come mainly from CDP. Firefox and Puppeteer reached production-ready BiDi support in Firefox 129 and Puppeteer 23, but CDP support in Puppeteer remained, and Chromium automation frequently still uses it.
Does BiDi make automation undetectable?
No. It removes one family of signals, the side effects of an attached CDP client, but navigator.webdriver, headless rendering differences, behavioural timing and network fingerprints are independent of which protocol carried the commands.
Does navigator.webdriver still appear under BiDi?
The WebDriver specifications tie that property to a browser being under remote control, and BiDi sessions participate in the same "webdriver-active" mechanism. How a particular browser build or framework configures it can vary, so check the documentation for your exact versions instead of assuming.
Why does BiDi matter to defenders?
Because a detector tuned to CDP side effects will silently under-report as more traffic moves to BiDi. Watching that signal's positive rate over time, and leaning on protocol-independent signals, keeps coverage steady.
