WebDriver BiDi: The Future of Browser Automation

WebDriver BiDi is a W3C protocol for browser automation that adds bidirectional, event-driven communication over a WebSocket. Classic WebDriver primarily sends an HTTP command and waits for its response. With BiDi, an automation client can also subscribe to browser events—such as navigation and log events—and receive notifications as they occur. It is an evolving extension to the WebDriver model, not a guarantee that every browser exposes every capability.

BiDi’s direction is useful when a test needs to observe browser activity without repeatedly polling, or when commands and events should share a standard automation protocol. Whether it is ready for a project depends on the browser, driver, framework, version, and specific BiDi module the project needs. The W3C document is a Working Draft dated 30 September 2026, so check current implementation data before choosing a stack. W3C Working Draft

1. How WebDriver BiDi works

In classic WebDriver, a client sends commands over HTTP and receives responses. That model works well for actions such as navigating to a page or finding an element, but observing asynchronous browser activity often leads to polling or framework-specific hooks.

BiDi uses a WebSocket connection for bidirectional messages. The client can send commands and subscribe to events; the browser can send event notifications over that connection. In plain terms, the client can be told that something happened instead of repeatedly asking whether it happened yet. MDN describes BiDi as event-driven communication between the automation client (the local end) and browser (the remote end). MDN WebDriver BiDi reference

Aspect	Classic WebDriver	WebDriver BiDi
Communication	HTTP request followed by a response	WebSocket messages in both directions
Events	Often polled for or exposed through framework-specific mechanisms	Browser can emit subscribed events to the client
Scope	Established WebDriver command model	WebDriver model extended with event-oriented modules and commands
Compatibility	Broadly established, but still driver-dependent	Varies by browser, driver, framework, version, and module

The practical difference is the communication model, not an automatic speed or reliability improvement. A BiDi event stream may simplify event observation, but test runtime and stability still depend on the test, application, browser, and implementation.

2. What BiDi is intended to enable

The protocol’s modules cover areas such as session and browser management, browsing contexts, scripts, logging, network activity, DOM interaction, and emulation. The exact commands and events available depend on implementation coverage. MDN’s module and event reference is a useful starting point for checking what the protocol describes. Browse the module reference

Observe navigation and contexts: receive notifications about navigation and browsing-context changes.
Collect logs: subscribe to browser log events, including console messages and JavaScript errors where implemented.
Inspect and execute scripts: use script-related commands and events exposed by the browser and client.
Monitor network activity: observe requests and responses, and support interception or mocking scenarios where the required feature is implemented.
Emulate browser conditions: use supported emulation capabilities for testing.
Capture and measure: the W3C explainer describes scenarios such as full-page screenshots and performance timings.

These are protocol capabilities and design scenarios, not a promise that a particular browser and automation library implement every item. The W3C WebDriver BiDi repository links to the evolving specification, compatibility data, and test suite. The W3C explainer describes scenarios including listening for DOM events, collecting logs, intercepting requests, recording traffic, and gradual interoperability with classic WebDriver.

3. A focused example: listen for browser log events

BiDi’s wire protocol is not usually something application tests should implement by hand. A WebDriver client library handles the WebSocket connection, session negotiation, subscription command, and event decoding. The following JavaScript example illustrates the shape of a subscription using Selenium’s WebDriver BiDi APIs. Selenium API names and support evolve; consult the documentation for the exact Selenium release and browser driver you use before adopting it.

import { Builder, logging } from 'selenium-webdriver';

const driver = await new Builder()
  .forBrowser('firefox')
  .setLoggingPrefs({ browser: 'ALL' })
  .build();

try {
  // BiDi must be enabled by the browser/driver and supported by this
  // Selenium release. Subscribe before navigating so early logs are observed.
  await driver.on(logging.Type.BROWSER, (entry) => {
    console.log(`[${entry.level}] ${entry.message}`);
  });

  await driver.get('https://example.com');
  // Perform assertions or actions here. Keep the session alive while
  // expecting asynchronous browser events.
} finally {
  await driver.quit();
}

This example uses a framework-level API: it does not expose raw BiDi messages and it should not be treated as proof that every browser/driver pair supports the same events. For a real test, verify whether the binding’s listener uses BiDi for your selected browser and release, subscribe before the activity you need to observe, and assert on a specific event rather than relying on console output alone. If you need a wire-level example, use the protocol’s current command and event definitions from the W3C specification instead of copying a stale message schema.

4. How to check browser and framework support

There is no useful universal yes/no answer to “Which browsers support WebDriver BiDi?” Support is a matrix: a browser may implement some modules, while a particular driver or framework version exposes only a subset through its public API. Check the exact feature path end to end.

Name the capability: for example, log events, navigation events, network observation, or a specific emulation command.
Check the current compatibility data: start from the compatibility resources linked in the W3C repository. Check the relevant module or command, not a generic BiDi badge.
Check the binding: read your framework’s release documentation for its BiDi APIs, defaults, and any explicit protocol-selection options.
Check the browser and driver versions: use a compatible pair and ensure the driver exposes a BiDi connection for the session.
Run a small capability test: start a session, subscribe to one required event, trigger it, and verify the payload. Run this in the same environment as CI.
Keep a fallback if needed: retain classic WebDriver or a browser-specific protocol for capabilities your chosen BiDi path does not yet provide.

A dated implementation example helps show why version-specific checks matter. On 7 August 2024, Chrome for Developers reported production-ready BiDi support in Firefox 129 and Puppeteer 23; it said Puppeteer used BiDi by default for Firefox while Chrome automation continued to default to CDP unless BiDi was explicitly requested. This is a historical example, not a current browser support matrix. Chrome for Developers, 7 August 2024

5. BiDi, classic WebDriver, and CDP

Choice	Communication and scope	When it may fit	Check before committing
Classic WebDriver	HTTP command/response model	Existing tests based on standard WebDriver commands	Driver behavior and any polling or event hooks your test depends on
WebDriver BiDi	WebSocket commands plus browser-to-client events, under a W3C protocol	Tests that benefit from standardized event observation and supported BiDi modules	Required module support across browser, driver, framework, and version
CDP	Chrome DevTools Protocol, with browser-specific capabilities	Automation that depends on Chrome-specific DevTools features	Portability needs and framework defaults; a BiDi path may not cover every CDP feature

BiDi’s standardization goal can improve the opportunity for portable automation, but it does not make every feature portable today. BiDi and CDP can coexist in a toolchain. The cited Puppeteer example uses different defaults for Firefox and Chrome, and the Chrome account notes that CDP remains useful for Chrome-specific automation. Choose based on required commands and events, portability needs, and migration cost—not on a general claim that one protocol is always faster or more stable.

6. A low-risk migration plan

Inventory the events and commands your tests actually need.
Choose one isolated test that currently polls or uses framework-specific event hooks.
Verify that your browser, driver, and library support the corresponding BiDi feature.
Subscribe to the event before triggering the action, and make the test wait for a meaningful condition with a bounded timeout.
Run the test repeatedly in local and CI environments and record failures by browser, driver, and library version.
Keep existing classic WebDriver flows for unaffected tests; migrate incrementally as the needed BiDi features become available in your stack.

This approach limits migration cost and gives the team concrete evidence about its own browser matrix. Avoid converting a whole suite just to change the transport if the suite does not need event-driven behavior.

7. Performance, reliability, and cost considerations

Performance

BiDi can reduce polling when a test needs to learn about browser events because the browser can send notifications over the open connection. That does not establish that a test or suite will run faster overall. Page load time, test waits, browser startup, network conditions, and framework implementation remain important. Measure the specific workflow before making performance claims.

Reliability

Event-driven observation can make some synchronization clearer, but events can be missed if the listener is attached too late, the session closes early, or the implementation does not support the event. Subscribe before the action, scope listeners to the relevant session or context, use bounded waits, and clean up listeners and browser sessions. Pin compatible browser, driver, and framework versions in CI.

Cost

The protocol itself does not set a usage price. Project cost comes from engineering time to validate support, maintain browser/driver/framework combinations, and migrate tests, plus whatever infrastructure runs the browsers. A narrowly scoped pilot helps estimate those costs before broad adoption. No adoption or performance statistics are needed to make that decision.

8. Troubleshooting

Symptom	Likely cause	What to do
No BiDi WebSocket or session endpoint is available	BiDi was not enabled, or the browser/driver/binding combination does not expose it	Check the framework’s BiDi setup instructions and session capabilities for the exact versions; confirm support in the compatibility data.
Unknown command or unsupported event	The implementation does not support that command/event, or the binding and browser versions differ	Check support for the specific module and command, update compatible components if appropriate, or use a supported alternative.
The event listener receives nothing	Subscription happened after the event, the wrong context was selected, or the browser does not emit that event through this implementation	Subscribe before navigation or action; verify context and event names; run a minimal test that triggers the event deliberately.
Test hangs waiting for an event	The event is not emitted or the wait has no useful deadline	Use a bounded timeout, log session setup and navigation failures, and fail with a diagnostic message that names the expected event.
Works locally, fails in CI	Different browser, driver, framework, or runtime versions, or a different session configuration	Pin and print versions in CI; run the same capability probe in both environments; avoid assuming local defaults apply to CI.
BiDi lacks a feature available through CDP	Feature coverage is not identical, and BiDi’s standard is still evolving	Keep the CDP path for that browser-specific requirement or redesign around currently supported BiDi commands.
Messages arrive but assertions are flaky	The test assumes event ordering or page readiness that the event does not guarantee	Assert on the relevant event fields and application state; do not treat a navigation notification as proof that all page work is complete.

9. Or skip the browser setup

If the immediate task is to capture a website screenshot rather than build a browser automation test, ScreenshotNeo provides a website screenshot API and MCP server for developers. A single GET request returns an image or PDF; the API examples below request a WebP screenshot. See the ScreenshotNeo documentation for parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers report the page verdict and whether the request was billed.
An MCP server gives AI agents tools for screenshots, page information, and PDF capture.
The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

10. FAQ

Does BiDi replace WebDriver classic?

It extends the WebDriver automation model with bidirectional communication. The W3C design includes gradual interoperability with classic WebDriver, so teams can migrate selected workflows instead of assuming every existing test must be rewritten.

Does BiDi work with every browser?

Support depends on the specific browser, driver, framework, version, module, and command. Check live compatibility data and run a small end-to-end capability test for your stack.

Is BiDi the same as CDP?

No. BiDi is a W3C protocol; CDP is a browser-specific protocol with its own feature set. Some automation frameworks can use both, depending on browser and task.

Is WebDriver BiDi finalized?

The cited W3C document is a Working Draft dated 30 September 2026. Treat the specification and implementation support as evolving, and check current sources when selecting versions.