Selenium vs Playwright: a standard against a framework

A protocol client against a framework

Selenium is a client library for the W3C WebDriver protocol. Your test calls a binding, the binding sends each command as an HTTP request to a driver process, and the driver, written by the browser vendor, turns it into browser actions. ChromeDriver, geckodriver, msedgedriver and safaridriver are separate implementations of one standard. That is why Selenium reaches real Safari and why every cloud grid accepts its sessions, and also why each command is a round trip and nothing waits for you beyond the page load.

Playwright holds one persistent connection to each browser it launches. It drives Chromium over the DevTools Protocol and ships its own patched Firefox and WebKit builds, which is why it cannot drive branded Firefox or Safari. In return, the browser pushes events such as requests, console messages and new pages to the test as they happen, and the API can check actionability before every click without a round trip per check.

The bigger difference is scope. Selenium deliberately stops at browser control, and the runner, waits, reporting and parallelism are yours to choose. Playwright Test arrives with all of them decided. Teams that compare a bare Selenium binding against Playwright Test are comparing a component with a product, and the result says more about the framework they never built than about WebDriver.

Where the flakiness really comes from

Selenium waits for document.readyState to reach complete and nothing else. Content rendered after load, spinners and buttons that enable later are invisible to the protocol, so every one of them needs an explicit wait that names the condition. Suites become flaky exactly where someone forgot one, or reached for a fixed sleep instead. Re-rendering frameworks add stale element references when a test holds an element across actions.

Playwright moves synchronisation into the API. Every action waits for its element to be visible, stable, enabled and unobscured, and assertions such as toHaveText retry until they pass or time out. Locators are lazy and re-evaluated on each use, so they do not go stale, and they are strict, so a selector that matches two elements fails instead of quietly picking the first.

A disciplined Selenium suite, with explicit waits inside page objects, an implicit wait left at zero and clean test data, can be just as stable. The difference is where the discipline lives. In Selenium it lives in your team’s conventions and code review; in Playwright it is the default behaviour, which matters most when the people writing tests change over time.

What each costs to run at scale

Neither tool charges a licence. Selenium’s costs are the framework engineering it leaves to you and the browser capacity it needs: a self-hosted Grid with its monitoring, image updates and capacity planning, or a cloud grid priced per parallel session. Grid also does not make tests parallel on its own. The runner has to open several sessions at once, which is configuration in TestNG, JUnit, NUnit or pytest-xdist.

Playwright Test runs workers by default and splits a suite across CI machines with a shard flag, so scaling out is a CI compute decision. Sharding shortens wall-clock time but not total machine time, and every shard repeats the install and browser download unless you use the official Docker image or a cache. Microsoft’s Playwright Workspaces on Azure is the only paid option, billed per minute of cloud browser time.

Where Selenium keeps a real advantage is heterogeneous capacity you own. A Grid with Windows, macOS and Linux nodes behind one endpoint, inside your network, is something Playwright has no equivalent for. Its documented Selenium Grid connection is experimental, covers Chrome and Edge only, and depends on a capability Selenium may not keep.

The language question is narrower than it looks

Both tools cover Java, Python, C# and JavaScript, so language only decides the matter for Ruby, where Selenium is the only official option. What differs is how much of each tool you get outside JavaScript. Selenium offers the same model in every binding, with WebDriver BiDi features arriving binding by binding, so check your language before designing around network capture.

Playwright publishes the same browser API for Python, Java and .NET, with tracing in all of them, but sharding, UI mode and the HTML report belong to the Node.js runner. A Python team uses pytest-playwright and pytest-xdist; a Java team uses JUnit or TestNG. That is still a large improvement on bare Selenium for waiting and stubbing, and it is less than the Playwright demos you have seen, which are almost always TypeScript. Note too that the Python package can trail the Node.js release: on 13 October 2026 PyPI listed 1.63.0 against 1.64 on npm.