What Is WebDriver? – Definition and How It Works
Learn what the WebDriver protocol is, how drivers translate commands for each browser, what the standard covers, and where its limits lie.
WebDriver is a W3C standard for controlling browsers remotely. A client sends HTTP requests describing actions; a driver process translates them into browser-specific instructions.
1. The Architecture
your script → WebDriver client library
→ HTTP requests to a driver process
→ browser-specific control
→ the browser
Each browser vendor supplies its own driver implementing the standard, which is what makes one script work across browsers.
2. What the Standard Covers
| Area | Commands |
|---|---|
| Sessions | Create, configure with capabilities, terminate |
| Navigation | Go to a URL, back, forward, refresh |
| Elements | Find, click, send keys, read text and attributes |
| Script execution | Run JavaScript in the page, synchronously or asynchronously |
| Cookies | Read, set, delete |
| Windows and frames | Switch between them, resize, position |
| Screenshots | Capture the page or an element |
| Alerts | Accept, dismiss, read text |
3. Capabilities
A session is created with a capabilities object describing what is wanted: browser name, version, platform, and browser-specific options such as command-line arguments or headless mode.
Capabilities are also how a remote grid decides which node should serve the session.
4. The Request-Response Shape
Each command is an HTTP request and each result an HTTP response, which makes WebDriver simple to implement, easy to proxy, and language-agnostic.
That same shape is its main limitation: it is a request-response protocol, so events happening in the browser cannot be pushed to the client. Waiting is therefore polling rather than subscription.
5. Standardisation Versus Speed
Being a W3C standard makes WebDriver broadly supported and stable, and it means new capabilities arrive through specification rather than by one vendor shipping them.
Lower-level protocols such as CDP expose more — network interception, fine-grained tracing, precise event streams — sooner, at the cost of being browser-specific.
6. WebDriver and Grids
Because commands are HTTP, a hub can route sessions to nodes running different browsers on different machines. That model is why distributed cross-browser testing has been practical for years.
7. Practical Notes
- Waits must be explicit. The protocol does not wait for actionability on your behalf.
- Driver and browser versions must match, and mismatches produce confusing errors.
- Element references go stale when the DOM re-renders, which surfaces as a stale-element error.
- Script execution is the escape hatch for anything the protocol does not cover directly.
8. Summary
WebDriver is a standardised, HTTP-based protocol for browser control, implemented by per-browser drivers and used through client libraries in many languages.
Its standardisation buys breadth and stability; its request-response design means explicit waits and no event stream, which is why lower-level protocols coexist with it rather than replacing it.