Playwright vs Selenium: Why We Made the Switch and Never Looked Back

Every flaky test that passes in CI and fails in production costs engineering velocity. The two frameworks that have defined browser automation for the past two decades handle that problem very differently. Selenium set the standard in 2004. Playwright arrived in 2020 and started taking market share fast. The data now shows how far that shift has gone.

The Numbers: npm Downloads and GitHub Activity

The week of May 27 to June 2, 2026, playwright logged 57,637,599 npm downloads. selenium-webdriver logged 2,056,944. That is a 28x gap in a single week.

The GitHub trajectory tells the same story. Playwright launched in January 2020 from Microsoft's developer tools team. In six years it accumulated 90,350 stars. Selenium's GitHub repository holds 34,156 stars from a project that began in 2004.

Note on forks: Selenium's higher fork count (8,686 vs 5,867) reflects its age. Many of those forks are legacy branches, unmaintained language bindings, and archived experiments accumulated across 20 years. It is not a sign of more active development.

The trajectory in weekly downloads tells an even starker story. Playwright barely registered in 2021. By 2023 it had overtaken selenium-webdriver in weekly downloads, and it has not looked back since.

A Brief History

Selenium launched in 2004 when Jason Huggins at ThoughtWorks needed to automate browser testing for a web application. The WebDriver API it produced eventually became the W3C WebDriver specification, which every major browser implements natively today. Selenium is the reason browser test automation is a standardized discipline at all.

Playwright came out of Microsoft in January 2020, built by engineers who had previously built Puppeteer at Google. The team had deep access to Chromium's DevTools Protocol and used it to write a framework from the ground up: one that assumed multi-browser support from day one, built waiting into every selector interaction, and shipped parallel test workers out of the box. Firefox and WebKit support followed within months of the initial release.

Head-to-Head: Feature Comparison

Feature	Playwright	Selenium
Auto-wait	Built-in on every action	Manual waits required
Browser support	Chromium, Firefox, WebKit	Chrome, Firefox, Safari, Edge, IE
Parallel execution	Native worker threads	Requires Selenium Grid
Network interception	Native (page.route)	Limited; requires external proxy
Mobile emulation	Built-in device profiles	Via Appium (separate project)
API testing	Built-in request fixture	Separate library required
Trace viewer	Built-in; generates .zip	None
Test recorder	npx playwright codegen	None native
Setup time from zero	~5 minutes	30 to 60 minutes
Language support	JS/TS, Python, Java, C#	Java, Python, C#, Ruby, JS

Translated into a developer experience scorecard across five key dimensions:

Ecosystem maturity is one area where Selenium retains a genuine edge. Twenty years of third-party integrations, reporting plugins, and institutional knowledge cannot be replicated quickly. That gap closes as Playwright's adoption accelerates, but it is a real consideration for teams with heavy existing tooling investments.

The auto-wait row is the most consequential difference in daily use. Selenium executes clicks and fills the moment the call is made; if the DOM element is not ready, the test fails. Developers compensate with time.sleep(), WebDriverWait, and expected_conditions: lines of code whose only job is to paper over timing. Playwright checks actionability before every interaction by default. The mechanism is not a timeout; it is a real check: the element must be visible, enabled, stable, and not obscured before Playwright acts.

Where Selenium Still Makes Sense

Existing large test suites in Java or C#. If your organization has 15,000 Selenium tests that pass reliably, the migration cost is real. Playwright supports Java and C# but the idiom differs meaningfully. Pick new features or new services as migration entry points rather than attempting a bulk rewrite.

IE11 requirements. Playwright targets modern browsers only and has no IE11 support. If your compliance environment requires test evidence against IE11, Selenium remains the only practical path.

Appium-based mobile testing. Playwright's mobile support is browser emulation: viewport sizing, user-agent overrides, and touch events. It does not test native iOS or Android apps. The Selenium ecosystem's Appium project handles native app automation. For teams that need hybrid web-and-native coverage in one framework family, Selenium's ecosystem is wider.

Contractual W3C WebDriver compliance. Some enterprise procurement requirements or regulated-industry standards specifically require W3C WebDriver compliance. Playwright uses its own internal protocol but shipped a limited WebDriver-compatible mode in 2024.

Why We Use Playwright at lowtouch.ai

We migrated our entire test suite to Playwright 18 months ago. These are the reasons it stuck.

Auto-wait eliminated a whole category of failures. We had CI failures that were pure timing issues: actions landing before React state had settled after an async update. Rewriting those tests with Playwright locators removed the root cause, not just the symptom. No sleep calls, no retry wrappers.

One tool covers UI and API. Our agentic workflow endpoints and the UI that invokes them are tested in the same test run, using the same playwright.config.ts, in the same CI job. The built-in request fixture sends authenticated API calls directly, without a second tool, a second config file, or a second CI step.

The trace viewer changed how we debug CI failures. When a test fails in CI, Playwright attaches a trace archive to the artifact. We open it locally with npx playwright show-trace, and step through every network request, every DOM snapshot, and every console log from the failed run. Time-to-root-cause dropped from hours to under 15 minutes for most failures.

codegen plus Claude Code accelerates test authoring. We open a browser session with npx playwright codegen https://app.lowtouch.ai, walk through a user flow, and get a complete test scaffold. We hand that to Claude Code with a prompt like "clean this up and add assertions for error states." The output is consistently idiomatic Playwright. It is not a substitute for deliberate test design, but it handles 80% of the boilerplate for straightforward happy-path flows.

Zero extra CI infrastructure. One npx playwright install --with-deps in the CI container installs the browsers. GitHub Actions has a maintained action for this. No Selenium Grid to configure, no additional service containers, no external browser farm.

Getting Started: 3 Commands

npm init playwright@latest
npx playwright test
npx playwright show-report

The init command creates playwright.config.ts, a sample spec, and a GitHub Actions workflow file. A minimal production config:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 1 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: [['html'], ['github']],
  use: {
    baseURL: process.env.BASE_URL ?? 'http://localhost:3000',
    trace: 'on-first-retry',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  ],
});

trace: 'on-first-retry' captures traces only on failure, keeping artifact sizes manageable in CI. Remove projects entries for browsers you do not ship to.

The Bottom Line

Playwright's 28x npm download advantage over selenium-webdriver and 2.6x GitHub star lead are not flukes. They reflect a framework that removed the primary source of test brittleness, unified UI and API testing in one tool, and shipped a debugging experience that scales across distributed CI. If you are starting a new project today, Playwright is the default. If you are on Selenium, pick a seam: a new microservice or a new feature branch. Start Playwright there. The migration does not have to be all-or-nothing.