Why Teams Switched from Selenium to Playwright

Playwright overtook Selenium because it solved the specific problems Selenium-era engineers spent their careers working around — flaky waits, brittle network mocking, slow cross-browser runs, debugging that ended at a screenshot. TestGuild's 2026 survey of more than 40,000 testers and TestDino's 2025 benchmark put Playwright adoption at roughly 45% of QA professionals versus Selenium at 22%, with Cypress steady around 14%. The State of JS 2024 survey gave Playwright a 94% retention rate — the highest among E2E testing tools tracked. This piece breaks down why those numbers landed where they did, what Selenium still does better, and how WebDriver BiDi is changing the math in 2026.

Key takeaways

• Playwright passed Selenium in adoption because of auto-wait, a single API across Chromium/Firefox/WebKit, first-class network mocking, the Trace Viewer, and parallel execution by default.
• Selenium is not dead — it leads on language coverage (Ruby, PHP, Perl), W3C WebDriver compliance, distributed testing via Grid, and decades of enterprise tooling.
• WebDriver BiDi in Selenium 4.4x and the in-development Selenium 5 narrow the architectural gap, particularly for real-time events, network interception, and console capture.
• For most teams, the right answer in 2026 is Playwright on new projects, Selenium maintained on legacy suites, and an honest audit before any wholesale migration.

---

How Selenium became the default — and then stopped being it

Selenium was written in 2004 at ThoughtWorks by Jason Huggins as an internal tool for testing a time-and-expenses web app. The protocol it eventually standardised — WebDriver, now a W3C recommendation — was designed for a browser landscape where each vendor shipped a proprietary internal model and the only practical handle was an external HTTP-driven bridge. For nearly two decades that was the right shape.

The WebDriver model carried a quiet tax engineers learned to live with. Every command travelled from the runner, over HTTP, to the WebDriver server, and into the browser. Synchronising that flow against a single-page application built with React or Angular meant either scattering sleep calls through the test code or wrestling with implicit waits that interacted unpredictably with dynamic content. Flakiness was a downstream consequence of an out-of-process protocol built for a less dynamic web.

Microsoft released Playwright in 2020, built by the team that had previously created Puppeteer at Google. Rather than talking to the browser over an external protocol, Playwright connects directly to each browser's DevTools protocol over a persistent WebSocket. That decision is what made automatic waiting feasible, native network interception possible, and multi-tab testing tractable instead of treacherous. The adoption curve that followed is the steepest the npm registry has ever recorded for a testing framework — under 1 million weekly downloads in 2021 to roughly 30–33 million weekly downloads in early 2026.

---

Playwright vs Selenium at a glance

---

Why Playwright won the adoption race

The decisive features were not flashy. They removed the categories of pain that defined the Selenium era.

Auto-waiting that reflects the DOM, not the clock

The single largest source of Selenium flakiness was timing. A test that worked locally failed in CI because the runner was slower. A test that passed Tuesday failed Wednesday because an API was a hundred milliseconds late. Teams spent disproportionate effort tuning time.sleep() calls and writing custom waiter helpers.

Playwright replaces that work with actionability checks. A click() waits until the element is attached, visible, stable, enabled, and able to receive events — not just present in the DOM. TestDino's 2025 analysis across 300+ test suites found Playwright produced roughly 67% fewer flaky tests than Cypress and a 20-percentage-point higher stability rate than Selenium (~92% vs ~72%). Auto-wait removes the biggest single category of failures that engineers used to debug by hand.

One API for Chromium, Firefox, and WebKit

Playwright ships managed browser binaries, including a build of WebKit — the engine behind Safari. The same test, with no driver configuration, runs against all three engines via a CLI flag. Cross-browser parity used to be the negotiation at the heart of every Selenium Grid setup; Playwright trades that for a couple of seconds at install. Selenium supports more browsers in production via cloud providers — Edge IE-mode, real Safari, obscure pairings — but for the routine "does this also work in Firefox?" loop, Playwright has eaten the friction.

Network mocking as a first-class primitive

In Selenium, mocking an API response meant standing up BrowserMob, running your own fake server, or layering Wiremock onto the test environment. Each was workable. None was cheap.

Playwright exposes page.route() directly. Intercept any request, modify it, mock the response, or abort it in a single line. For teams that test UI states against backend permutations — empty states, error states, slow networks, paginated edges — the cost of building those tests fell by an order of magnitude.

The Trace Viewer

Selenium's debugging story ended at the screenshot taken when the test failed plus whatever logs the runner emitted. The Trace Viewer flips the model. Playwright records the full timeline of a test — every action, every DOM snapshot, every network request, every console message, the source code for every step — and packages it into a single trace.zip. When CI fails at 03:00, you open the file in your browser and step through the test as if you were there. Time-to-root-cause collapses from "schedule a debugging session" to "scrub the trace timeline."

Codegen that produces a real starting point

Playwright ships playwright codegen — a browser-based recorder that watches your interactions and emits test code in your chosen language. The output is not production-grade, but it gives a junior QA engineer or a developer outside the test team a working scaffold instead of a blank file. Selenium IDE existed; its output was famously fragile. Playwright's recorder produces code closer to what an experienced engineer would write by hand.

Parallel by default, with browser contexts instead of full processes

Playwright runs tests in parallel across worker processes by default. Within a worker, browser contexts give each test a clean, isolated profile — cookies, storage, permissions — without the cost of launching a fresh browser. A large suite that took 40 minutes serially on Selenium Grid often lands at 5–10 minutes on the same hardware under Playwright. That is not marketing; it is what falls out of the architecture.

A faster, lighter execution loop

TestDino's benchmark across 300+ suites reported Playwright running roughly 42% faster than Selenium, with lower memory consumption per worker. The cause is architectural — no HTTP round-trip per command, no separate driver process, browser contexts instead of fresh browser launches. Speed that compounds across hundreds of tests is the difference between PR feedback in seven minutes and PR feedback after lunch.

---

What Selenium still does better

The adoption shift is not a verdict that Selenium is bad. The verdict is more specific: Selenium is no longer the default for new JavaScript-ecosystem projects, and it has stopped winning on developer experience. Outside those two facts, it still wins meaningful ground.

Language breadth. Playwright supports TypeScript/JavaScript, Python, Java, and .NET. Selenium supports those plus Ruby, PHP, and Perl, with deeper, more idiomatic bindings in several. A Rails team using Capybara still has the smoothest path with Selenium.

W3C WebDriver compliance. Selenium implements an actual W3C standard. In regulated industries — finance, public sector, healthcare — the ability to point at a standards document and a compliant implementation can decide procurement. Playwright's DevTools protocol approach is not a W3C standard.

Selenium Grid and the cloud provider ecosystem. Grid remains the most widely understood pattern for distributed testing across heterogeneous OS-browser-device combinations. BrowserStack, Sauce Labs, LambdaTest, and similar providers all have decade-old Selenium integrations and battle-tested capabilities for real Windows machines, specific older browser versions, and edge-device matrices. Playwright has cloud support, but the depth is not equivalent.

Existing investment. Many enterprises run Selenium suites with thousands of tests, internal frameworks, and tribal knowledge accumulated over a decade. Rewriting that wholesale is a real-money decision with real risk. The honest play for these teams is strangler-fig, not migration.

Mobile-adjacent automation. Appium, the most common framework for native mobile testing, descends from the Selenium WebDriver protocol. Teams sharing patterns between web and mobile suites often find Selenium's mental model maps more cleanly.

Mature training and documentation ecosystem. The Stack Overflow corpus, the Udemy catalogue, and the book inventory still weigh more heavily toward Selenium. The gap is narrowing, but on day one of a new hire's onboarding, Selenium answers are easier to find.

---

WebDriver BiDi: Selenium's serious response

The most important Selenium story of 2025–2026 is WebDriver BiDi — a bidirectional W3C protocol that runs over WebSockets alongside classic WebDriver. Classic WebDriver is request/response. BiDi is request/response plus a push channel: the browser can stream events — console logs, network requests, DOM mutations — to the test runner in real time.

That is the architectural piece Selenium engineers were missing. With BiDi, network interception is native (no proxy required), console messages stream to the test without polling, auto-wait improvements built on real-time events become possible, and latency overhead drops because high-frequency events stop fanning out into individual HTTP round-trips.

Selenium 4.4x has shipped progressively richer BiDi support through 2025 and 2026. Selenium 5, in active development, is built around BiDi as a first-class surface rather than a bolt-on. The honest summary from the field is that BiDi achieves functional parity for individual features, not architectural parity. Browser contexts, the integrated Trace Viewer, codegen, and the cohesive single-API experience remain Playwright advantages. But the gap between "Selenium with BiDi" and "Playwright" is meaningfully smaller in 2026 than the gap between Selenium 3 and Playwright 1.0 in 2020. For enterprises with large Selenium investments, BiDi is the difference between "we must migrate" and "we can modernise in place."

---

Migration: what actually works

If your team has decided to move toward Playwright, or is weighing the choice, a few patterns separate the migrations that finish from the ones that stall.

Audit the suite before you migrate anything

Not all tests are equal. Some are high-value, run on every commit, and break promptly when production breaks. Others were written three years ago, fail intermittently, are skipped in CI, and nobody is quite sure what they were meant to verify. Migration is a forcing function to delete the second category. A Selenium suite of 800 tests often becomes a Playwright suite of 300 better tests.

Don't attempt a big-bang rewrite

The migrations that fail are the ones treated as a project to convert every existing test. The migrations that finish use the strangler-fig pattern: write new tests in Playwright from day one, run both suites in parallel in CI, and migrate the highest-value Selenium tests opportunistically when you touch them. The Selenium suite shrinks naturally until what remains is small enough to retire.

Rethink your Page Object patterns

The Page Object Model was developed inside the Selenium era and has been the default abstraction for a decade. Playwright supports POM, but its fixtures system and component-level abstractions are often a better idiomatic fit. Use the migration to ask whether your abstraction layer earns its keep, rather than porting Selenium POMs class-for-class.

Train the team's instincts, not just their syntax

Engineers who have written Selenium for years have habits that need adjustment. The biggest: manually inserted waits in Playwright are not just redundant — they actively mask bugs by introducing timing slack that hides real race conditions. The first refactor pass on a migrated test should remove every waitForTimeout that survived the conversion.

Plan for CI changes

Playwright's bundled browser binaries are large downloads. CI pipelines that don't cache them correctly see startup time balloon. The Playwright docs cover caching for GitHub Actions, GitLab CI, and others — a step many teams skip until they notice CI got slower the week after migration.

---

What this means for QA teams day-to-day

The shift is not just a tooling decision. It changes how teams are organised and what skills they need.

TypeScript familiarity moves from useful to expected. Playwright is most widely used in TypeScript form. The ecosystem, the examples, the community content all skew there. QA engineers historically rooted in Python or Java can still use Playwright, but TypeScript fluency has become a practical prerequisite for engaging fully with the surrounding ecosystem.

The line between developer testing and QA testing blurs. Playwright's ergonomics make it accessible to developers who would never have touched a Selenium suite. Component testing, visual regression testing, and API mocking — work that lived firmly in QA's column under Selenium — increasingly land alongside feature code. This is a structural change in how QA relates to engineering, not just a tool preference. The future of QA roles, as we've covered before, reflects this.

Faster tests reveal slower handoffs. Playwright makes it easier to run large suites quickly. That speed advantage compounds only if failures get diagnosed and fixed at the same pace. A test failure that takes two days of back-and-forth wastes the speed gained in execution. The bottleneck shifts from "how fast do we run tests" to "how fast do we resolve what they find."

---

A practical stance for 2026

The adoption data is clear enough to inform decisions without inviting panic. The reasonable posture for most testing teams:

• New project starting today? Playwright. The ecosystem, documentation, and community have reached the point where it is the lower-risk default.
• Existing Selenium suite running well? Don't migrate as a project in its own right. Write new tests in Playwright, migrate opportunistically when you touch existing tests, and let the Selenium suite shrink naturally.
• Selenium suite largely broken or unmaintained? Migration is worth treating as prioritised work — but use it to audit what you actually need to test, not just to port broken tests into a new framework.
• Large enterprise Selenium investment with regulatory or polyglot constraints? Watch Selenium 5 and BiDi closely. The modernise-in-place path is more credible than at any point since 2020.

For a deeper side-by-side that also covers Cypress, the Selenium vs Playwright vs Cypress 2026 comparison walks through the trade-offs in more detail. For the broader landscape of test automation frameworks in 2026, the catalogue continues past these three.

---

FAQ

Why did teams switch from Selenium to Playwright?

Auto-wait, native network mocking, a single API across Chromium/Firefox/WebKit, the Trace Viewer, parallel-by-default execution, and roughly 42% faster suite runs. Each one removed a category of work that Selenium left to engineers.

Is Selenium dead?

No. TestDino's 2025 data shows Selenium at ~22% adoption — declining relative to Playwright, but still the framework of choice for tens of thousands of enterprises, polyglot teams, regulated industries, and legacy suites. WebDriver BiDi and Selenium 5 narrow the gap meaningfully.

What is WebDriver BiDi?

BiDi is a W3C bidirectional protocol that runs over WebSockets alongside classic WebDriver. It lets the browser push events to the test runner in real time — console logs, network requests, DOM mutations — which enables native network interception, lower-latency auto-wait, and richer debugging in Selenium 4.4x and the upcoming Selenium 5.

Should I migrate an existing Selenium suite to Playwright?

Only with intention. Audit the suite first, retire dead tests, write new tests in Playwright from day one, and migrate the high-value Selenium tests opportunistically. Avoid big-bang rewrites — they are the most common reason migrations stall.

Does Playwright support more languages than Selenium?

No. Selenium supports more languages — including Ruby, PHP, and Perl — which Playwright does not. Playwright currently covers TypeScript/JavaScript, Python, Java, and .NET.

Is Playwright faster than Selenium?

Yes, in most cases. TestDino's benchmark across 300+ suites measured Playwright at roughly 42% faster than Selenium, with lower flake rates and lower memory consumption per worker. The cause is architectural: a persistent WebSocket connection to the browser, browser contexts instead of fresh browser launches, and parallel-by-default execution.

---

Make your bug reports as fast as your tests

Whichever framework your team runs — Playwright, Selenium, Cypress, or a mix — the rate at which bugs actually get fixed is gated by the quality of the report that reaches the developer, not by how quickly the test caught the regression.

Crosscheck is a free Chrome extension built for the moment a bug surfaces — in a CI failure, in a QA session, in production. It captures a screenshot or screen recording, the full console log, every network request, and environment details (browser, OS, viewport) in one report, then sends it to Jira, Linear, ClickUp, Slack, or GitHub. No paid tiers, no usage limits.

Playwright made your test suite faster. Crosscheck makes the bugs your suite catches — and the ones your exploratory testers find — faster to diagnose and close. For more on how that workflow plays out, see our guide to the perfect bug report template.

Try Crosscheck free