Playwright vs Selenium vs Cypress
Selenium, Playwright, and Cypress are the three dominant tools for browser-based end-to-end testing, but they take fundamentally different architectural approaches. Selenium (2004) communicates with browsers over the W3C WebDriver protocol via a separate driver executable (chromedriver, geckodriver) for each browser, giving it the broadest browser and language support of the three but also the most moving parts and the most exposure to protocol-translation flakiness. Playwright (2020) talks to browsers over each engine's native debugging protocol directly from the test process, without a separate driver binary, which reduces one whole layer of indirection compared to Selenium.
Cricket analogy: It's like Selenium being an older format where instructions pass through a translator to each foreign umpire (a driver binary per browser), while Playwright is a player who speaks the umpire's language directly, cutting out the translation step entirely.
Waiting Strategy and Flakiness
Selenium scripts historically required explicit waits (WebDriverWait with expected conditions) because the WebDriver protocol has no built-in concept of actionability, and skipping this step is the single most common cause of flaky Selenium suites. Cypress runs inside the browser itself (not out-of-process like the other two), which gives it excellent built-in retry-ability for commands and assertions, but restricts it to Chromium-family browsers and (more recently, experimentally) WebKit, and it cannot easily drive two origins or two tabs in one test the way Playwright and Selenium can. Playwright's auto-waiting for actionability is built into every action by default, giving Cypress-like retry ergonomics while still running out-of-process like Selenium, which is what lets it support true multi-tab, multi-origin, and multi-context scenarios in a single test.
Cricket analogy: It's like Selenium being a bowler with no umpire's guidance on over-stepping (you must manually check the front-foot line every ball), Cypress being confined to bowling only from one specific end of the ground, and Playwright being a bowler with automatic no-ball detection who can bowl from either end.
Choosing Between Them
Selenium remains the right choice when a project needs to test genuinely legacy browsers, integrate with an existing large WebDriver-based grid, or use a language binding (like Ruby or PHP) that Playwright doesn't officially support. Cypress remains popular for tightly-scoped component and frontend-integration testing where its in-browser architecture and excellent developer experience (time-travel debugging in its own runner, automatic reloading) shine, especially for teams already deep in a single-origin React or Vue app. Playwright tends to win for full end-to-end suites spanning multiple real browsers, tests that need multiple tabs or origins (like OAuth redirects to a third-party login), and teams that want first-class parallelization and tracing without stitching together extra tooling.
Cricket analogy: It's like choosing Selenium when you must play on an older, heritage ground with unusual dimensions (legacy browsers), Cypress when you're focused purely on intense net-practice drills in one dedicated net, and Playwright when you need a squad ready to tour and perform across every ground format.
// Playwright can drive two origins/tabs in a single test — harder to do cleanly in Cypress
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch();
const context = await browser.newContext();
const appPage = await context.newPage();
await appPage.goto('https://app.example.com/login');
const [oauthPopup] = await Promise.all([
context.waitForEvent('page'), // new tab opened by OAuth redirect
appPage.getByRole('button', { name: 'Sign in with Google' }).click(),
]);
await oauthPopup.waitForLoadState();
await oauthPopup.getByLabel('Email').fill('[email protected]');
await oauthPopup.getByRole('button', { name: 'Next' }).click();
await browser.close();
})();Feature comparisons date quickly — Cypress has added experimental WebKit and multi-origin support in recent versions, and Selenium 4 added a BiDi protocol to close some gaps with Playwright. Always check each tool's current release notes rather than relying on a comparison written even a year earlier.
A useful rule of thumb: reach for Playwright by default for new full-stack E2E suites, keep Selenium only where an existing large grid or an unsupported language binding forces your hand, and consider Cypress for teams whose testing needs are tightly scoped to a single-origin frontend app with heavy component-testing needs.
- Selenium uses the W3C WebDriver protocol via separate driver binaries per browser, giving the broadest language/browser support but more moving parts.
- Cypress runs inside the browser itself, giving strong built-in retry-ability but historically limited to Chromium-family browsers and single-origin testing.
- Playwright talks to each browser engine's native protocol directly, out-of-process, combining auto-waiting with true multi-tab/multi-origin support.
- Selenium's lack of built-in actionability waiting is a leading cause of classic flaky test suites.
- Playwright natively supports scenarios like OAuth popups and multiple tabs within a single test.
- Choose Selenium for legacy browser/language needs, Cypress for tightly-scoped single-origin frontend testing, Playwright for broad cross-browser E2E suites.
- Tool capabilities evolve quickly; verify current docs rather than relying on older comparisons.
Practice what you learned
1. What protocol does Selenium use to communicate with browsers, and how?
2. Where does Cypress's test runner execute relative to the browser?
3. What is a leading historical cause of flaky Selenium test suites?
4. Which capability does Playwright natively support that is historically harder to achieve cleanly in Cypress?
5. According to the recommended rule of thumb, when should you reach for Selenium over Playwright?
Was this page helpful?
You May Also Like
What Is Playwright?
An introduction to Playwright, Microsoft's cross-browser automation and end-to-end testing framework, and why teams choose it over older tools.
Your First Playwright Test
Writing, running, and understanding a first real Playwright test, from locators and actions to assertions and the HTML report.
Browsers, Contexts, and Pages
Understanding Playwright's core object model — Browser, BrowserContext, and Page — and how it enables fast, isolated test execution.