WebDriver BiDi (bidirectional) is a W3C standard automation protocol that lets a script send commands to and receive events from a real browser over a single bidirectional connection — a vendor-neutral, cross-browser replacement for the Chrome DevTools Protocol (CDP) that Selenium, and increasingly Playwright and Puppeteer, are migrating browser control onto.
CDP is Chromium's own proprietary debugging protocol — Puppeteer, Selenium's Chromium driver, and Playwright for Chromium all drive the browser by connecting to it over CDP, which is also why CDP-specific detection techniques (the Runtime.enable getter leak covered elsewhere in this glossary) work against all three. WebDriver BiDi is a W3C-standardized protocol instead, designed jointly by Google, Mozilla, and other browser vendors, so it works the same way across Chromium, Firefox, and WebKit rather than being Chrome-specific.
Selenium has moved furthest on adoption, treating CDP as a legacy fallback while shifting its DevTools-style capabilities onto BiDi; Playwright currently uses BiDi to drive Firefox but still drives Chromium over CDP as of 2026. The practical effect is that a script's automation surface — and its detectability — now depends on which protocol a given tool uses for a given browser engine, not just which library the script imports.
BiDi removes the specific CDP artifacts anti-bot vendors have spent years cataloguing — the Runtime.enable getter leak, the __playwright_binding__-style global, ChromeDriver's older cdc_-prefixed properties — because those tells are specific to CDP's command structure, not to automation in general. That's a real, documented gap in detection coverage today.
It isn't a stealth guarantee, though: BiDi introduces its own control-channel surface, and detection research is actively mapping equivalent side effects for it, the same way it did for CDP over the preceding several years. BiDi also still exposes less low-level access than CDP — network interception, JavaScript profiling, and DOM snapshots have no full BiDi equivalent yet — so tools that need that granularity stay on CDP regardless of the detection tradeoff, keeping CDP-based automation the norm for Chromium scraping through 2026.
How Crawlora handles this
Crawlora's browser-rendering layer tracks which control protocol and which patches actually avoid detection for a given target and engine, rather than defaulting to whichever protocol a library ships out of the box — the same reason a raw Playwright-over-CDP or Selenium-over-BiDi setup alone isn't a finished anti-detection strategy.
Glossary
FAQ
Not yet, as of 2026. Selenium is furthest along in shifting its DevTools-style capabilities onto BiDi, and Playwright uses it to drive Firefox, but Playwright and most Chromium automation still runs over CDP because BiDi doesn't yet match CDP's granular network interception and profiling access.
No — it avoids the specific CDP-based tells anti-bot vendors have documented, like the Runtime.enable getter leak, but it opens its own control-channel surface that detection research is actively studying. Treat it as a different, less-mapped set of signals, not immunity.
Selenium 4+, Playwright (currently for Firefox), and Puppeteer have all added BiDi support at varying levels of maturity — check each project's current documentation, since the split between BiDi and CDP usage per browser engine is still shifting.
Beyond WebDriver BiDi, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.