These two are more alike than most comparisons suggest. Both drive the browser from outside it, as a separate process sending commands. That shared design is why both handle multiple tabs, multiple domains and multiple windows without ceremony, and it is the thing that separates them together from Cypress.
So the choice is not about architecture. It comes down to three things: who does the waiting, what ships in the box, and how far each one reaches.
Difference 1: who does the waiting
This is the one that changes your daily work more than any other.
Playwright waits for you. Before it clicks, it checks the element is attached, visible, stable, enabled and not covered. Its assertions retry too. So this just works, even if the button appears half a second later:
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByText('Saved')).toBeVisible();
Selenium makes you ask. It has no automatic waiting for content. You say what to wait for, and every time you forget, you get a test that passes on your machine and fails on a slower one:
await driver.wait(until.elementLocated(By.css('[data-testid="toast"]')), 10000);
const toast = await driver.findElement(By.css('[data-testid="toast"]'));
Skipping that wait is the single most common cause of flaky Selenium suites. It is not that Selenium is unreliable. It is that nothing in the tool stops you writing an unreliable test, so reliability becomes a discipline your team has to hold.
There is a second consequence people meet later. Selenium's findElement hands you a reference to a real element, which can go stale when the page re-renders. Playwright's locators are descriptions that get looked up again on each use, so they never go stale. That is why StaleElementReferenceException is a Selenium rite of passage and a phrase Playwright users never learn.
Difference 2: what ships in the box
Playwright is a framework. Test runner, assertions, fixtures, parallel execution, retries, HTML reports and a trace viewer, all in one install. You can write a real suite the day you start.
Selenium is a library. It drives browsers. That is the whole job. There is no runner, no assertion library, no configuration system, no reporting and no waiting.
// Selenium: assertions come from somewhere else entirely
const { expect } = require('chai');
expect(await driver.getTitle()).to.equal('Dashboard');
So every Selenium team builds the same six layers: configuration, a driver factory, a wait library, page objects, data helpers and reporting. Built well, that is a real framework tuned to your product. Built badly, it is the reason the suite is slow and nobody trusts it.
The practical effect is on onboarding. A new engineer joins a Playwright team and writes a useful test on day one. A new engineer joins a Selenium team and first has to learn that team's private framework, which nobody outside the company has documentation for.
The trace viewer deserves its own mention. When a Playwright test fails in CI, you get a recording: every action with timings, the DOM before and after each step, network requests, console output. You can open the page as it was at the moment of failure and inspect it. Selenium gives you a screenshot and whatever logging you built yourself. For debugging a failure you did not see, the gap is large.
Difference 3: reach
This is where Selenium wins, and it is not close.
Selenium is built on WebDriver, a W3C standard that browser makers implement themselves. That buys reach nothing else matches:
- Languages: Java, Python, C#, Ruby, JavaScript and more, all first class.
- Browsers: anything implementing WebDriver, including real Safari on macOS, Edge, and older enterprise browsers.
- Longevity: it is a web standard. It will still work in ten years, which matters in regulated industries that need that promise in writing.
Playwright bundles its own browser builds: Chromium, Firefox and WebKit. It supports TypeScript, JavaScript, Python, Java and .NET.
Two honest caveats people gloss over. Playwright's WebKit is a build of the WebKit engine, not Safari itself, so it catches engine differences but is not identical to testing real Safari. And Playwright is a Microsoft project with its own protocol and patched browser builds, not a standard implemented by browser vendors. For most teams that is irrelevant. For a company whose compliance rules require a standards-based tool, it is decisive.
Neither tool automates native mobile apps. That is Appium's job, whichever you pick.
Speed
Playwright is faster, and the reason is structural rather than a matter of tuning.
Every Selenium command is an HTTP round trip to a driver process. Locally that is a millisecond or two and invisible. Against a remote Grid it might be 30ms, and a test making a hundred calls pays that a hundred times. Playwright keeps one persistent connection and does its waiting inside the browser rather than polling from outside.
That said, the tool sets your floor and your setup decides your actual runtime. A Selenium suite that arranges data through the API and runs on adequate Grid capacity will beat a Playwright suite that logs in through the form for every test. Most slow suites are slow because of interface setup and missing parallelism, not because of the tool.
One more practical difference: Playwright's parallel execution is built in and free. Selenium scales through Grid, which you host, size and maintain yourself.
So which should you choose?
Choose Playwright when:
- You are starting something new and the language choice is open.
- You want reliable tests without making waiting a team discipline.
- You want good debugging of failures you did not watch happen.
- You need multiple tabs, origins or parallel runs without extra infrastructure.
Choose Selenium when:
- Your team's language is Ruby, or another language Playwright does not support. This decides it on its own.
- You must test real Safari, or an old browser a large customer still runs.
- You have a large, working suite that catches real bugs today. That has value a rewrite would destroy for months.
- Your organisation requires a standards-based tool with a long support horizon.
- You have already invested in Grid infrastructure and the people who run it.
Should you migrate?
Usually no, and the reason is worth saying plainly: a migration costs months and ends with exactly the coverage you already had. That is a difficult thing to show a manager.
Migration earns its cost in two situations. When the current tool genuinely blocks something you need. Or when the suite is so unreliable that you are rewriting the tests anyway, in which case moving while you rewrite is nearly free.
"Selenium is old" is not a business case. "We cannot test our checkout because it spans two domains" is.
If you do migrate, do it gradually: stop writing new Selenium tests, move the most valuable ones first, run both suites during the transition, and delete each old test as it is replaced. We cover the mechanics in Selenium to Playwright.
Remember this
They share an architecture, so this is not a fight about design. Playwright gives you waiting, tooling and speed for free. Selenium gives you reach, standards and language coverage nothing else matches. Choose for your team's language, your browser requirements and the suite you already have, not for which tool is newer.
New to both? Start with the Playwright tutorial or the Selenium WebDriver tutorial, then write a real test in the practice editor.