Playwright is a batteries-included browser automation tool from Microsoft that ships its own patched browser builds, a test runner and a debugger. Selenium is a W3C-standardised protocol with language bindings that drive the real browsers you already have installed, and nothing else: no runner, no assertions, no reporting.
Pick Playwright if you are starting fresh on a web app and want parallel runs, auto-waiting and a trace viewer on day one. Pick Selenium if you need real Safari, a language Playwright does not support, or you already have infrastructure and a test framework you are not going to replace.
Both projects are active. Playwright shipped 1.64 on 7 October 2026. Selenium shipped 4.51.0 on 9 October 2026, its third release in a month. Everything below was checked on the vendors' own pages on 12 October 2026.
The short version
| Playwright | Selenium | |
|---|---|---|
| Latest release | 1.64, 7 Oct 2026 | 4.51.0, 9 Oct 2026 |
| What it is | Tool with a bundled runner | W3C Recommendation plus bindings |
| Browsers | Patched Chromium, Firefox, WebKit; branded Chrome and Edge on request | The real Chrome, Edge, Firefox, Safari, Internet Explorer |
| Languages | JavaScript/TypeScript, Python, Java, .NET | Java, Python, C#, Ruby, JavaScript |
| Waiting | Automatic, before every action | You write it |
| Parallel runs | On by default | Grid, or your own runner |
| Post-run debugging | Trace Viewer | No first-party equivalent |
| Mobile | Emulation only | Not covered |
| Test runner included | Yes | No |
What each one actually is
This is the difference that explains most of the others.
Selenium WebDriver is a W3C Recommendation. The project's own docs put it in the first line. It defines a protocol, browser vendors implement it in their drivers, and Selenium ships bindings in five languages that speak it. Selenium does not include a test runner, an assertion library or a reporter, because those are not its job. You bring JUnit or pytest or NUnit and wire it up.
Playwright is a product. It bundles the runner, the assertions, test isolation, parallelism and the tooling, and it ships its own browser binaries to do it. That is why npx playwright test works out of the box and a Selenium project needs a framework decision before you write a line.
Neither of those is the better answer in the abstract. If your organisation already standardised on TestNG and has eight teams using it, Selenium slots in and Playwright asks you to adopt a second runner. If you are one team starting this week, Playwright saves you a day of setup you will otherwise redo badly.
Browsers: what "cross-browser" means in each
Playwright's cross-browser story is narrower than the marketing suggests, and the docs are honest about it.
Playwright ships patched builds. Its browsers page says Playwright "doesn't work with the branded version of Firefox since it relies on patches", and says the same about Safari. The WebKit it drives is built from WebKit main-branch sources, not Safari. 1.64 bundles Chromium 156, Firefox 157 and WebKit 27.2. You can point it at the real installed Chrome or Edge by setting a channel, and those two are the only branded browsers it drives.
Selenium drives the real thing. Its browsers page lists Chrome, Edge, Firefox, Safari and Internet Explorer: the actual installed, branded applications your users run.
Whether that matters depends on what you have promised. A WebKit build will surface plenty of Safari-specific layout and CSS behaviour, because it is the same engine. It is not Safari, and if your acceptance criterion is literally "it works in Safari", Playwright cannot give you that and Selenium can. A technical lead at a SaaS company we spoke to in September put it well and then talked himself out of it in the same breath: Safari would be nice to have, and "most of the people right now is Chrome, because Edge is also Chrome now in the latest Windows". That is roughly where the market is.
One thing worth checking before you commit: Playwright's supported-OS floor has moved up. The install page now requires macOS 14 or later, Windows 11 or Windows Server 2019 or later, and Node 22, 24 or 26. On older build agents, that is the blocker, not the feature list.
Languages
Playwright supports four: JavaScript and TypeScript on Node, Python, Java and .NET. Its languages page says all core features work in all four.
Selenium ships five stable bindings: Java, Python, C#, Ruby and JavaScript.
Ruby is the one that decides it. If your test estate is Ruby, the comparison ends here.
Waiting: the difference you feel every day
Everything else on this page is architecture. This is the part that shows up in your week.
Playwright waits for you. The actionability docs say it "performs a range of actionability checks on the elements before making actions" and "auto-waits for all the relevant checks to pass and only then performs the requested action". For a click, that means the locator resolves to exactly one element, and the element is visible, stable (not mid-animation), enabled, and not obscured by something else. You do not write any of that.
Selenium asks you to. Its waits docs describe an implicit wait, a global setting that defaults to zero so an element that is not there "will immediately return an error", and explicit waits, which are "loops added to the code that poll the application for a specific condition". There is a FluentWait class in Java for customising the polling interval and the ignored exceptions.
And there is a warning, in bold, on Selenium's own page: "Do not mix implicit and explicit waits. Doing so can cause unpredictable wait times."
That sentence is doing a lot of work. It describes a specific and familiar shape: somebody set a global implicit wait years ago, everyone since has layered explicit waits on top, and the suite now waits for an amount of time nobody can predict. Playwright does not have that failure mode, because there is nothing to mix.
What Playwright does have is a different one. Auto-waiting makes the easy case easy, which means nobody learns what the tool is waiting for, and when a test fails on a race the author has no mental model to debug it with. Both tools can produce a suite that passes in the morning and fails at four. They get there by different routes. We have written separately about the two kinds of flaky test and why one of them is worth keeping.
Parallel runs
Playwright runs test files in parallel by default. The docs say so in the first line: workers are separate OS processes, each with its own browser, and you cap them from the command line or the config. Across machines, --shard=2/3 splits the suite with a flag.
Selenium has no runner, so it has no opinion. Parallelism comes from your test framework, or from Grid, which lists "an easy way to run tests in parallel on multiple machines" as a design goal and ships as a real component architecture: router, distributor, session map, queue, nodes, event bus, all versioned alongside the bindings at 4.51.0.
The fair way to put it: Playwright parallelises on one machine for free. Selenium parallelises once you stand something up, and what you stand up fans out across operating systems and browser versions that Playwright has no way to reach.
Debugging after the fact
Playwright's Trace Viewer is the single biggest quality-of-life gap between the two. It records a trace you open after the run: the locator used for each action and how long it took, a film strip of screenshots, full DOM snapshots per action, console and network logs filtered to the selected action, and the line of source that produced it.
Selenium has no first-party equivalent. The nearest things are Selenium IDE for record-and-playback, and BiDi's logging and network namespaces for capturing console output and requests live. In practice teams get screenshots and video from Grid or a cloud provider.
If you spend a lot of time asking "what did the page look like when that failed", this is the whole argument.
WebDriver BiDi, and what it is not yet
BiDi comes up in every version of this comparison, usually overstated.
Selenium's position on it is in its own docs: it is "the W3C standard bidirectional protocol for browser automation", the project helped create it with the browser vendors, it is "the cross-browser replacement for the Chrome DevTools Protocol", and Selenium is "updating its entire implementation from WebDriver Classic to WebDriver BiDi".
What it is not, yet, is finished. The spec is an Editor's Draft dated 8 October 2026, and it says on its face that "it is inappropriate to cite this document as other than a work in progress". You can see the port happening in the release notes rather than in an announcement: 4.51 added a BiDi code generator for Java and extension install over BiDi for JavaScript with a fallback to classic commands, 4.50 added BiDi screenshots and screencast handling for .NET.
So: real, shipping incrementally, co-developed with the browser vendors, and not something to make a 2027 architecture decision on today.
What changed in 2026 on both sides
Anyone writing this comparison from 2025 knowledge gets the next two sections wrong.
Playwright stopped describing itself as a test framework. The homepage tagline is now "reliable web automation for testing, scripting, and AI agents", and the three products listed are Playwright Test, Playwright CLI and Playwright MCP. Test Agents ship in the box: a planner, a generator and a healer, installed with npx playwright init-agents, with setup paths for VS Code, Claude Code, Codex and OpenCode. A first-party agent that repairs failing tests is a 2026 fact. Component testing also went stable this year and the old @playwright/experimental-ct-* packages were removed entirely, so anyone still on them is pinned to 1.62 until they migrate.
Selenium started writing for agents, and said why. On 29 September the project published "Using AI agents with Selenium", which makes the observation that a lot of Selenium code is now written by coding agents and "it is wrong in the same handful of ways every time": an unnecessary driver-manager dependency, an outdated DesiredCapabilities object, absolute XPath copied out of DevTools, sleep(5). The diagnosis is that the agent "was just taught by the internet of 2015" and "will also be describing Selenium 3". The fix shipped alongside it: an AI-agents documentation section with a curated llms.txt that deliberately excludes the legacy docs, an examples directory that runs against current releases in CI so it cannot rot quietly, and a paste-ready rules block for AGENTS.md whose sharpest line is that if an API cannot be found in the current documentation, it does not exist.
That second one matters more than its coverage suggests. The reason your coding agent writes bad Selenium is not that Selenium is bad. It is that fifteen years of Stack Overflow answers are in the training data and three of them are current. Selenium is the only one of these two projects that has written down what to do about it.
One thing to know if you are on Java: 4.51 is a breaking change. ExpectedCondition no longer implements Guava's com.google.common.base.Function. Code that explicitly types a variable or parameter as the Guava Function will not compile. Grep for com.google.common.base.Function before you upgrade; the fix is a one-line import swap. The project wrote it up separately on 21 September.
Migration: what it actually costs
The honest answer is that nobody we talk to has a number, and the ones who have done it describe the cost in the same two places.
The first is the parts of the suite that are not tests. A QA engineer on a team carrying more than 10,000 Cypress tests told us this autumn that they were migrating "the main part" to Playwright and would plan the rest afterwards, and the thing they asked about first was not assertions or selectors. It was the custom commands shared across hundreds of tests, and the environment handling for local VMs, shared servers and a weekly release, which had to work identically on all of them. Framework A to framework B is a find-and-replace. Your abstractions are the migration.
The second is who can write the new ones. A technical lead at a SaaS company described a team of two QA engineers where one is fluent in Playwright, and said that asking developers to write Playwright "is not really working. And it's like a loop, basically." Switching frameworks does not change the number of people who can maintain a suite in it.
There is also a decent case for not migrating. A QA lead at a financial services firm told us other teams there were moving off "traditional Selenium Java frameworks" to Playwright and seeing value, which is a real pattern. But an engineering manager on a twelve-year-old product, with three developers and two testers, told us his Selenium regression run goes out every Friday and he was not looking to replace it. He wanted something for the pull request instead. His suite works. The right move was to leave it alone.
Which one fits your team
New web project, team of any size, Chrome-first. Playwright. The setup cost is a morning, the waits are free, and the trace viewer will save you more hours than anything else on this page.
Safari in your acceptance criteria, or Ruby in your stack. Selenium. This is not close.
Existing Selenium suite that works. Keep it. Spend the migration budget on coverage you do not have. Our co-founder Vilhelm von Ehrenheim's version of this, from a customer call in August: if you already have four thousand Playwright tests coded and that works, keep doing that.
A large organisation with a standard runner and shared infrastructure. Selenium costs you less politically and fits what is already there. Grid is doing a job Playwright has no equivalent for.
You need the suite to run on hardware you control, across OS and browser combinations. Selenium and Grid.
Mobile. Neither, directly. Playwright emulates a device: user agent, viewport, touch events. It never claims real hardware, and there is no native app support. Selenium's docs describe no mobile story either.
Where both of them leave you
Both tools do the same job well, and it is worth being precise about what that job is: they execute steps you wrote, against selectors you chose, and tell you whether the assertions you specified passed. Everything they verify, somebody decided to verify in advance.
That is fine while the suite is small. It stops being fine at the size most teams reach, which is why we argue that a large regression suite is a liability rather than an asset. Runs get slow, a one percent per-test flake rate guarantees a red every run, and nobody dares delete anything. Neither Playwright nor Selenium has an answer to that, because it is not a framework problem.
Compare the efficacy of agentic QA against traditional script-based regression testing frameworks and the difference is not the execution, it is what decides the scope. The shape we recommend is a small scheduled regression suite covering the flows that must never break, paired with dynamic testing on each pull request that works out what the change can affect and checks that. QA.tech, an AI testing platform, does the second half with agents that read the diff and exercise the running product rather than replaying a script. It will not do what Playwright does: if you need a scripted check of an exact DOM state in CI, write it in Playwright. What it removes is the part where coverage of a new feature requires somebody to write and then maintain a new test for it. If you are weighing either framework against that model, we have written up Playwright alternatives and Selenium alternatives in more detail, and there is a direct QA.tech vs Playwright comparison.
And if the real question behind "Playwright or Selenium" is "which modern framework", the other one to look at is Cypress. We compared Playwright vs Cypress earlier this month.
FAQ
Is Playwright better than Selenium? For a new web project on Chromium-based browsers, usually. Playwright gives you auto-waiting, parallel runs and a trace viewer with no setup, and Selenium gives you none of those without assembling them. For real Safari, for Ruby, or for an existing estate built on a standard runner, Selenium is the better fit and it is not a close call.
Is Selenium still maintained in 2026? Yes. Selenium 4.51.0 shipped on 9 October 2026, after 4.50 on 30 September and 4.49 on 9 September. The project is also actively porting its implementation from WebDriver Classic to WebDriver BiDi, a protocol it helped write with the browser vendors.
Does Playwright test in real Safari? No. Playwright drives a patched build of the WebKit engine, and its own docs say it "doesn't work with the branded version of Safari since it relies on patches". The same is true of Firefox. Only Chrome and Edge can be driven as the real installed browser. Selenium drives real Safari.
Is WebDriver BiDi a finished standard? Not yet. As of 8 October 2026 the specification is a W3C Editor's Draft that states it is inappropriate to cite as anything other than a work in progress. Selenium is implementing it incrementally, release by release.
How long does it take to migrate from Selenium to Playwright? No team we have spoken to has given us a number, and the test code is not usually the expensive part. Budget for the shared helpers and custom commands, the environment and test-data handling, and the fact that fewer people on the team will be able to maintain the result on day one than could maintain the old suite.
Why does my coding agent write bad Selenium? Because most Selenium code on the public internet is Selenium 3, and that is what the model learned. Selenium published guidance for this in September 2026: a curated llms.txt that excludes the legacy documentation, examples that run in CI against current releases, and a rules block for AGENTS.md telling the agent that an API it cannot find in the current docs does not exist.
Can I use both? Yes, and plenty of teams do, usually by accident rather than design. The reasonable version is Selenium for the cross-browser and legacy coverage that only it can reach, and Playwright for new work. The unreasonable version is two suites covering the same flows, which doubles the maintenance and halves the trust in both.
