WebDriver
Before WebDriver, browser automation tools mostly worked by injecting JavaScript into a page, which meant they were bound by the same sandbox restrictions as any other script on that page. WebDriver took a different approach: instead of running inside the browser, it talks to a driver process built for that specific browser, such as chromedriver or geckodriver, and the driver translates each command into whatever native calls that browser needs. That out-of-process design is what lets WebDriver open new windows, handle native dialogs, and generally act with the same reach a real user has.
The protocol itself is just a specification, a set of HTTP endpoints and a JSON wire format for actions like navigating to a URL, finding an element, or sending keystrokes. Any tool that implements it, on either end, can interoperate: a client library written in Java can drive a browser vendor's own driver binary without either side needing to know about the other's internals. The Selenium project is the best-known client, but the protocol itself is bigger than any one library, which is why the W3C standardized it as a formal recommendation in 2018 rather than leaving it as a de facto convention.
WebDriver's classic request-response model has a known limit: the browser can only speak when spoken to, so it cannot push events like a console log or a new network request to the script on its own. WebDriver BiDi, a newer W3C specification built on WebSockets, adds that missing direction. Selenium has been rolling BiDi support into its 4.x releases and is retiring its older Chrome DevTools Protocol integration in favor of it, since BiDi works the same way across browsers instead of being tied to Chromium.
What the protocol actually covers
- Session management, starting and ending a controlled browser instance with a chosen set of capabilities.
- Navigation and browsing context, loading URLs and switching between windows, tabs, and frames.
- Element location and interaction, finding elements by selector and sending clicks, text input, and other actions to them.
- JavaScript execution and document inspection, running scripts in the page and reading back the resulting DOM state.
- WebDriver BiDi extends this with bidirectional events for network traffic, console messages, and JavaScript exceptions.
Where WebDriver shows up
- Selenium, which uses WebDriver as its core mechanism for driving Chrome, Firefox, Edge, and Safari.
- Appium, which extends the same protocol to automate native and hybrid mobile apps on iOS and Android.
- Browser vendors themselves, since Chrome, Firefox, and Edge each ship a WebDriver-compatible driver binary as part of supporting the standard.
- Cloud device and browser grids, which expose remote sessions over the same protocol so a test written once can run against infrastructure it never has to know about directly.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| A vendor-neutral, W3C-backed standard, so a script isn't locked to one browser's proprietary automation hooks. | The protocol itself is low-level, it defines commands, not test structure, waiting, or assertions, which is left to whatever client library sits on top. |
| Out-of-process control reaches native dialogs and multi-window behavior that in-page scripts can't touch. | The classic request-response model can't push events, which is exactly the gap WebDriver BiDi exists to close. |
| The same protocol extends beyond browsers to mobile automation through Appium. | Each browser's driver binary is a separate moving part to install, version, and keep in sync with the browser itself. |
Frequently asked questions
Is WebDriver the same thing as Selenium?
No. WebDriver is the W3C protocol, and Selenium is a project that implements a client for it, along with extra tooling like Selenium Grid. Selenium is the most visible user of WebDriver, but the protocol also underlies other tools, including Appium.
What is WebDriver BiDi?
It is a newer W3C protocol that adds two-way, WebSocket-based communication to WebDriver, so a browser can push events like network requests or console logs to a script instead of only responding to commands. It is meant to replace the browser-specific DevTools protocols that tools like Selenium previously relied on for that capability.
Does WebDriver work for mobile app testing?
Not directly by itself, since the base spec targets web browsers. Appium builds a WebDriver-compliant server on top of it that extends the same commands and concepts to native and hybrid iOS and Android apps, so teams that already know WebDriver can carry that knowledge over.
How Klarent helps
Klarent's AI agents work above the protocol layer entirely, so a team gets self-healing test execution across web, mobile, desktop, and API surfaces without writing or maintaining WebDriver-level scripts by hand.