How does Selenium WebDriver work under the hood?

At its core Selenium is a client library that speaks a standard protocol to a browser automation server. Understanding the layers explains most of the errors you will ever debug.

The layers

1. Language binding. Your Java, Python, C# or JavaScript code calls methods such as driver.findElement(By.id("email")). The binding turns each call into a WebDriver command.
2. The W3C WebDriver protocol. Commands are HTTP requests with JSON bodies, for example POST /session/{id}/element with {"using": "css selector", "value": "#email"}. Since Selenium 4 the bindings speak only the W3C dialect; the old JSON Wire Protocol is gone.
3. Browser driver. chromedriver, geckodriver, msedgedriver or safaridriver is a small HTTP server that receives those commands and drives the browser through its internal automation interface.
4. The browser. It executes the action and the driver returns a JSON response (a value, or an error such as no such element, which the binding maps to NoSuchElementException).

When you use Selenium Grid, a Grid server sits between the binding and the driver, but the protocol is the same, which is why RemoteWebDriver code looks identical to local code.

WebDriver driver = new ChromeDriver();            // Selenium Manager finds/downloads chromedriver
driver.get("https://example.com/login");          // POST /session/{id}/url
WebElement email = driver.findElement(By.id("email")); // POST /session/{id}/element
email.sendKeys("qa@example.com");                 // POST /session/{id}/element/{elementId}/value
driver.quit();                                    // DELETE /session/{id}

Selenium Manager

Since Selenium 4.6, Selenium Manager ships with the bindings. If no driver is on the PATH, it detects the installed browser version, downloads the matching driver and caches it. It can also fetch a browser (Chrome for Testing, Firefox) when one is requested by version. This removed the need for third-party helpers like WebDriverManager in most projects, although teams on locked-down networks often still pin drivers explicitly.

WebDriver BiDi

Classic WebDriver is request/response: the client asks, the browser answers. It cannot push events such as console logs or network requests. Selenium 4 first exposed Chrome DevTools Protocol (CDP) for this, which is Chromium-only and version-coupled. The W3C WebDriver BiDi specification adds a WebSocket channel that works across browsers, and Selenium is progressively moving features (log listeners, network interception, script evaluation) onto BiDi.

Why this matters in practice

• A “session not created” error almost always means a browser/driver version mismatch or a missing browser, which is the driver layer, not your test.
• Every command is a network round trip, so chatty code (looping over hundreds of findElement calls) is slow, especially against a remote Grid.
• Because the driver only knows the DOM state at the moment of each command, synchronisation is your job. That is why waits matter so much.

What interviewers look for

• You can name the layers: binding, protocol, driver, browser.
• You know Selenium 4 is W3C-only and that Selenium Manager handles drivers.
• You can connect the architecture to real problems: version mismatches, latency and synchronisation.

Common mistakes

• Saying Selenium “injects JavaScript into the page” (that was Selenium RC, and it is closer to how Cypress works).
• Believing you still must download chromedriver manually for every Chrome update.