Selenium 4: What's New and What Every QA Must Know in 2026

Last updated: October 2026

Quick answer

Selenium 4 was released on October 13, 2021, and it is still the current major version. The latest stable release on selenium.dev is 4.50.0 (September 30, 2026). The changes every QA engineer should know are: W3C WebDriver is the only protocol, relative locators, Chrome DevTools Protocol (CDP) access giving way to the WebDriver BiDi standard, Selenium Manager for automatic driver setup, and a rebuilt Selenium Grid 4.

Selenium 4 at a glance

Feature	What it does	Status in 2026
W3C WebDriver protocol	Standard browser communication; legacy JSON Wire Protocol removed	Default since 4.0
Relative locators	Find elements by position: above, below, left of, right of, near	Stable
CDP access	Chrome DevTools features such as network interception and console logs	Chromium only; described by Selenium as temporary; removed for Firefox in 4.29.0
WebDriver BiDi	Standard, cross-browser, two-way protocol replacing CDP	W3C Working Draft; Selenium is moving its implementation to it
Selenium Manager	Finds, downloads and caches drivers (and browsers) automatically	Bundled since 4.6; still labeled beta
Selenium Grid 4	Rebuilt Grid with standalone, hub-and-node and distributed modes	Stable; Docker and Kubernetes friendly

W3C WebDriver is now the only protocol

The biggest under-the-hood change in Selenium 4 is that it “removes support for the legacy protocol and uses the W3C WebDriver standard by default.” WebDriver became a W3C Recommendation in June 2018, and browser vendors ship their own drivers that follow it. Work on the next level of the spec continues as a W3C Working Draft.

Here is what this means for your tests:

• Capabilities: use standard names such as browserVersion and platformName instead of version and platform. Vendor-specific settings need a prefix, such as cloud:options.
• Options classes: use ChromeOptions, FirefoxOptions and similar classes instead of DesiredCapabilities.
• Java API cleanup: the old findElementBy* methods are gone. Use findElement(By...).
• Timeouts: waits and timeouts take a Duration, for example Duration.ofSeconds(10).

Because every browser speaks the same standard protocol, tests behave more consistently across Chrome, Firefox, Edge and Safari.

Relative locators

Relative locators let you find an element by where it sits on the page in relation to another element. The available methods are above, below, toLeftOf, toRightOf and near, and you can chain them. For example, you can find “the button below the email field and to the right of Cancel.”

They work by comparing the rendered bounding boxes of elements. That makes them useful when an element has no stable ID or class, but it also means they depend on layout. A responsive design that moves elements at a different screen size can change which element matches. Use them as a complement to IDs, names, data attributes and CSS selectors, not a replacement.

From CDP to WebDriver BiDi

Chrome DevTools Protocol (CDP)

Selenium 4 added access to CDP, which unlocked features like network interception, basic and digest authentication, console log capture and JavaScript error detection. The catch is that CDP is tied to Chromium and changes between browser versions. Selenium’s docs state that “CDP support is temporary until WebDriver BiDi has been implemented” and that Selenium supports only the three most recent Chrome versions for CDP.

Firefox has already moved on. Starting with Firefox 129, CDP is no longer enabled by default, and Selenium 4.29.0 fully removed CDP support for Firefox in February 2025.

WebDriver BiDi

WebDriver BiDi is the standard, two-way protocol that Selenium created together with the browser vendors as the cross-browser replacement for CDP. Classic WebDriver is request and response. BiDi opens a WebSocket so the browser can push events to your test, such as console messages, network activity and DOM changes.

Status in October 2026:

• The specification is a W3C Working Draft (latest dated September 30, 2026), so it is still evolving.
• Google described WebDriver BiDi as production-ready in both Firefox and Chrome as of August 2024.
• Selenium is moving its implementation from WebDriver Classic to BiDi while keeping backward compatibility as much as possible. You turn it on by setting the webSocketUrl capability to true.

If you write new code that relies on CDP, check whether a BiDi equivalent exists first. It will be more portable and less likely to break when the browser updates.

Selenium Manager: no more manual driver downloads

Driver version mismatches used to be one of the most common causes of broken Selenium runs. Selenium Manager, introduced in Selenium 4.6, is a Rust command-line tool that ships with Selenium and runs automatically. It detects your browser version, downloads a matching driver and caches it.

Since Selenium 4.11 (Chrome), 4.12 (Firefox) and 4.14 (Edge), it can also download and manage the browsers themselves. In most projects you can now delete WebDriverManager-style setup code and hard-coded driver paths. Selenium Manager is still versioned as 0.x because the project labels it beta, so pin your Selenium version in CI and keep an eye on release notes.

Selenium Grid 4

Grid was rebuilt from scratch for Selenium 4. It routes WebDriver commands to remote browsers so you can run tests in parallel across machines, browsers and versions. You can run it three ways:

• Standalone: all components in one process, started with java -jar selenium-server-<version>.jar standalone. It is good for local work and CI.
• Hub and Node: a central hub with nodes on other machines.
• Distributed: each component runs separately for large, containerized setups.

In distributed mode, the components are the Router, Distributor, Session Map, New Session Queue, Event Bus and Nodes. Grid 4 also added Docker support, a GraphQL endpoint and OpenTelemetry tracing for observability, which help when you need to debug why a session was slow or never started.

Upgrading to the latest Selenium 4 release

1. Update the dependency to the current 4.x release in all language bindings you use.
2. Remove manual driver management and let Selenium Manager handle drivers.
3. Replace DesiredCapabilities with browser Options classes and standard capability names.
4. Fix deprecated APIs, such as findElementBy* and numeric timeouts.
5. Audit CDP usage, especially anything that targets Firefox, and move to BiDi where possible.
6. Upgrade Grid nodes and hub together, then run your full suite before switching CI over.

Selenium 4 or codeless testing?

Selenium 4 is a strong, open standard, but you still need people who can write and maintain code. If your team would rather spend its time on test design than on framework upkeep, a codeless testing approach can sit alongside Selenium or replace it for web regression suites.

CloudQA is a codeless test automation platform for web applications. You record tests with the CloudQA Chrome extension and edit them visually, adding steps, assertions, waits, variables, data sets or custom JavaScript, with no code to maintain. It handles Shadow DOM and iframes, waits automatically for page loads and AJAX, and runs tests in the CloudQA cloud on Chrome, Firefox and Edge, in parallel or on a schedule. You can trigger runs from CI/CD tools such as Jenkins or Azure DevOps through CloudQA APIs.

Runs are deterministic: recorded steps and locators run exactly as written. If a step fails because its element can’t be found, CloudQA tries to locate the right element and reports the recovery for review. Learn more about building and maintaining tests and running them across browsers and environments, see pricing, or sign up free.