How does a WebDriver work?

A WebDriver works by turning every line of your automation code into an instruction that a real browser can carry out. When you call a method such as get, findElement, or click, the WebDriver client serializes that command into an HTTP request and sends it to a browser driver. The driver translates the request into the browser's native automation, performs the action, and sends back an HTTP response with the result. WebDriver itself is a WebDriver that defines this interface, and Selenium WebDriver is the most widely used implementation of it.

What Is a WebDriver?

WebDriver is a W3C Recommendation, which means it is an official web standard rather than a single vendor's tool. It specifies a language-neutral interface and wire protocol for remotely inspecting and controlling a browser, the same way a person would by clicking, typing, and navigating. Because it is a standard, the same set of commands behaves consistently whether you automate Chrome, Firefox, Edge, or Safari.

Selenium WebDriver is the implementation most testers mean when they say WebDriver. It ships as a set of open-source client libraries in Java, Python, C#, JavaScript, and Ruby, paired with the browser drivers that actually execute the commands. The key idea is that WebDriver drives the browser natively using its own automation hooks, so your test interacts with the real UI instead of relying on injected JavaScript workarounds.

How Does a WebDriver Work, Step by Step

Here is what happens behind the scenes when you write WebDriver code and run it:

• Your code issues a command: a call such as driver.get(url) or element.click() is captured by the WebDriver client binding in your language of choice.
• The command becomes an HTTP request: the binding serializes the command into a structured HTTP request and sends it to the browser driver's REST endpoint. Every WebDriver command maps to a specific endpoint and HTTP verb.
• The browser driver translates it: ChromeDriver, GeckoDriver, msedgedriver, or safaridriver receives the request and converts it into the browser's native automation instructions.
• The browser performs the action: the real browser executes the instruction, whether that is loading a page, locating an element, or sending keystrokes.
• The result travels back: the browser returns the outcome to its driver, which sends an HTTP response containing a status and any value, such as an element reference or visible text, back to your script.

This request-and-response cycle repeats for every command in your test. If a step fails, the response carries an error or exception, which your automation framework surfaces as a failed assertion or a thrown exception.

The WebDriver Architecture

WebDriver has a clean three-layer architecture. Understanding the layers makes it obvious why a test can fail at the driver level even when your code is correct.

• Client bindings: the language-specific libraries you import into your test project. They expose a friendly API such as findElement and sendKeys, and they handle serializing your commands into the WebDriver protocol and parsing the responses.
• Browser driver: a standalone executable that exposes a local HTTP/REST server and understands the W3C WebDriver protocol. Each browser has its own driver, maintained alongside the browser itself, so it always knows how to control the current version.
• Browser: the real Chrome, Firefox, Edge, or Safari instance where your pages actually render and your actions actually run.

The table below maps each browser to the driver that controls it:

The Session Lifecycle

Every WebDriver run is wrapped in a session, and the session is what ties all of your commands to one specific browser instance.

• Session start: creating the driver, for example new ChromeDriver(), sends a New Session command. The driver launches the browser and returns a unique session ID.
• Commands carry the session ID: every subsequent request includes that session ID, so the driver always knows which browser window the command belongs to.
• Session end: calling driver.quit() sends a Delete Session command, which closes the browser and frees the resources. Forgetting to quit leaves orphaned browser processes and driver instances running.

The W3C WebDriver Protocol and Why the JSON Wire Protocol Was Removed

The wire protocol is the contract that defines how the client and the driver talk to each other. This is the part of WebDriver that changed most significantly in recent years, and it explains why modern Selenium is more stable.

• The old way (JSON Wire Protocol): in Selenium 3 and earlier, the client spoke the JSON Wire Protocol while browsers were moving toward the W3C standard, so the driver had to encode and decode between the two. That translation layer was a common source of inconsistency across browsers.
• The transition: Selenium 3.8 through 3.141 supported both the JSON Wire and W3C protocols at the same time, bridging the gap during the migration.
• The current way (W3C WebDriver protocol): the JSON Wire Protocol was removed in Selenium 4. The client, the driver, and the browser now all speak the same W3C protocol natively, so there is no translation step. The result is fewer cross-browser quirks and less flaky behavior.

A Quick Code Example

The short Java example below shows the full life of a session. Each highlighted line corresponds to one or more HTTP requests sent to ChromeDriver under the hood.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.By;

public class WebDriverFlow {
    public static void main(String[] args) {
        // 1. Creating the driver sends a "New Session" command and returns a session ID
        WebDriver driver = new ChromeDriver();

        // 2. Each call below is sent to ChromeDriver as an HTTP request
        driver.get("https://www.lambdatest.com");          // navigate
        driver.findElement(By.name("q")).sendKeys("test");  // locate + type

        // 3. quit() closes the session and the browser
        driver.quit();
    }
}

Notice that you never write any HTTP code yourself. The client binding hides the protocol, which is exactly what makes WebDriver feel like a normal programming API.

Running WebDriver Remotely with RemoteWebDriver and Selenium Grid

Everything so far assumes the browser runs on the same machine as your test. In practice, teams often need to run on many browser and operating system combinations at once, which is where remote execution comes in.

• RemoteWebDriver: a class that implements the same WebDriver interface but targets a remote endpoint instead of a local browser. Your test code stays identical; only the URL of the endpoint changes.
• Selenium Grid: a hub-and-node setup that distributes sessions across multiple machines and browsers, so the same suite can run in parallel.
• Cloud grids: a managed alternative that removes the need to maintain your own infrastructure, drivers, and OS images.

Because RemoteWebDriver only needs an endpoint, you can point it at a cloud Selenium Automation to run your existing WebDriver tests across 3,000+ real browsers and operating systems without managing any local drivers. The request-and-response flow is exactly the same; the browser simply lives in the cloud rather than on your laptop.

WebDriver BiDi: Beyond Command and Response

Classic WebDriver is one-directional: you send a command and wait for a response. WebDriver BiDi is a newer bidirectional protocol that runs alongside the classic W3C protocol and adds a real-time channel. Instead of only issuing commands, your test can subscribe to browser events and stream console logs, network requests, and other introspection data as they happen. This makes it far easier to debug, capture errors, and assert on activity that used to be invisible to a pure command-and-response model.

Frequently Asked Questions

Is WebDriver a tool or a protocol?

Both. WebDriver is a W3C standard that defines a language-neutral interface and wire protocol for controlling a browser. Selenium WebDriver is the popular implementation of that standard, made up of client bindings plus the browser drivers that actually carry out the commands.

How does a WebDriver communicate with the browser?

Each method you call, such as get, findElement, or click, is serialized into an HTTP request and sent to the browser driver's REST endpoint. The driver translates the request into the browser's native automation, performs the action, and returns an HTTP response containing a status and any value, such as the text of an element.

What is a browser driver in WebDriver?

A browser driver is a standalone executable that sits between your test and the browser. ChromeDriver, GeckoDriver, msedgedriver, and safaridriver each understand the W3C WebDriver protocol and know how to control their specific browser. Your script talks to the driver, and the driver talks to the browser.

Was the JSON Wire Protocol removed in Selenium 4?

Yes. The legacy JSON Wire Protocol was retired in Selenium 4. Selenium 3.x ran both the JSON Wire and W3C protocols, which required an encode and decode step. Selenium 4 speaks the W3C WebDriver protocol natively, so the client and the browser share the same language and the translation layer is gone.

What is the difference between WebDriver and RemoteWebDriver?

WebDriver typically launches a browser on the same machine as your test. RemoteWebDriver implements the same WebDriver interface but points at a remote endpoint, such as a Selenium Grid hub or a cloud grid, so the browser runs on another machine while your code stays the same.

What is WebDriver BiDi?

WebDriver BiDi is a newer bidirectional protocol that runs alongside the classic W3C WebDriver protocol. Instead of a one-way command and response, it lets your test subscribe to browser events and stream console logs, network activity, and other introspection data back in real time.

• What Is Selenium WebDriver?
• What Are the Different Types of Drivers Available in WebDriver?
• What Are the Different Components of the Selenium Suite?
• What Is Selenium Grid?
• What Is Object Repository in Selenium WebDriver?