Skip to main content
TBS Tech Services

Playwright vs Selenium vs Cypress in 2026

By TBS Tech Services QA team. Published

In our view, Playwright suits most new web app suites, Selenium suits large existing suites or teams that need its language range and WebDriver standard, and Cypress suits JavaScript-only teams who like its in-browser workflow. Each has real limits. This guide uses each project's own documentation and no benchmarks.

What are Playwright, Selenium and Cypress?

All three drive a real browser so you can test a web app the way a person uses it. Playwright and Cypress are testing tools in their own right. Selenium is an umbrella project of browser automation tools, and its WebDriver part is a W3C Recommendation. We checked each claim below against the project's own documentation.

  • Playwright is open source under the Apache-2.0 licence and lives in the microsoft organisation on GitHub.
  • Selenium is open source under the Apache-2.0 licence.
  • The Cypress test runner is open source under the MIT licence. Cypress Cloud is a separate service.

How do they compare at a glance?

The table summarises what each project's documentation says today. Read it as a starting point, not a verdict. Differences in languages, waiting and parallel runs matter most for day-to-day work, while browser coverage and tab handling decide whether a tool can test your app at all.

Playwright, Selenium and Cypress compared, from each project's own documentation
TopicPlaywrightSeleniumCypress
LanguagesJavaScript and TypeScript, Python, Java and .NETLanguage bindings including Java, Python, C#, JavaScript and RubyJavaScript only. Its documentation says JavaScript is the only language it will ever support
BrowsersChromium, Firefox and WebKit on Windows, Linux and macOSUses the browser vendors' own automation APIs. Its documentation has pages for Chrome, Edge, Firefox and SafariChrome-family browsers, Firefox and WebKit
What you getA test runner, assertions, isolation, parallelization and tooling in the Node.js package. Other languages use a framework such as pytest, JUnit, TestNG, MSTest, NUnit or xUnitBrowser automation (WebDriver), plus IDE and GridA test runner whose code runs inside the browser
WaitingAutomatic checks before actions (visible, stable, enabled, receives events), and assertions that retryYou choose and configure implicit or explicit waits. Its documentation says not to mix themQueries and assertions retry up to a default timeout, and actions wait for their checks to pass
Parallel runsTests run in parallel by defaultSelenium Grid runs tests on different machines across platformsIts documentation says parallel runs require recording to Cypress Cloud
Tabs and originsEach browser context can host multiple pages (tabs)Windows and tabs are handled with window handles that you switch betweenControls one browser at a time. Multiple tabs need a plugin, and each test is bound to a single superdomain, with cy.origin for cross-origin steps
LicenceApache-2.0Apache-2.0MIT (test runner)

What are the strengths and limits of each?

No tool wins everywhere. Each point below comes from the project's own documentation, and we say so where we’re giving a view instead. We haven’t benchmarked speed or flakiness for this guide, and we don’t claim that any of the three is faster or less flaky in general.

Playwright

Strengths:

  • It waits for elements to be ready before acting, and its assertions retry.
  • The Trace Viewer lets you step through a recorded test with its log, network, errors and console.
  • One API drives Chromium, Firefox and WebKit.
  • It has several official languages, and a built-in test runner for Node.js.

Limits:

  • It’s a web testing tool. Mobile support is emulation of Chrome for Android and Mobile Safari.
  • Outside Node.js you choose and set up the test framework yourself.

Selenium

Strengths:

  • WebDriver is a W3C Recommendation, and Selenium provides infrastructure for that specification.
  • Language bindings for Java, Python, C#, JavaScript and Ruby are documented.
  • Selenium Grid runs tests on different machines across platforms.

Limits:

  • Synchronization is yours to manage. Its documentation calls races between browser state and commands one of the primary causes of flaky tests.
  • Implicit and explicit waits shouldn’t be mixed, so a team needs one clear convention.

Cypress

Strengths:

  • Its commands retry and its actions wait for checks to pass, so tests rarely need hard-coded waits.
  • Test code runs in the browser, which is the basis of its workflow.
  • The test runner is MIT licensed.

Limits:

  • JavaScript is the only language.
  • It controls one browser at a time, and multiple tabs need a plugin.
  • Each test is bound to a single superdomain.
  • Cypress lists native and mobile events and full iframe support as trade-offs.
  • Parallel runs require recording to Cypress Cloud.

When should you choose each?

This is our view, not a rule. Pick the tool that fits your team and your app, then prove it with a small pilot. Playwright is our default for new web app suites. Selenium fits some existing estates, and Cypress fits some JavaScript-only teams.

  • Choose Playwright for a new web app suite, when you need WebKit coverage, want tracing built in, or want to write tests in TypeScript, Python, Java or .NET.
  • Choose Selenium when you have a large, stable suite, when your team works in a language Playwright doesn’t list, such as Ruby, or when you rely on Selenium Grid or WebDriver compatibility.
  • Choose Cypress when your team writes only JavaScript, your tests stay within one origin, and you value its in-browser workflow.

Should you migrate an existing suite?

Not automatically. A stable suite your team trusts doesn’t need to move because a tool is newer. Migration pays off when tests are slow or flaky, when the old tool blocks something you must test, or when upkeep costs more than the tests save. If you do move, migrate in stages.

We plan and run these moves as our Selenium and Cypress migration service, and the guide to migrating from Selenium to Playwright shows the method. To build a new suite, see Playwright test automation services.

How can you test the choice on your own app?

Run a small pilot. Write the same handful of important user journeys in each tool against your app. Run them repeatedly in your own pipeline, and compare how long they take, how often they fail without a real bug, and how much effort each one took to write and fix. Your own results matter more than any general benchmark.

Where does this information come from?

Every fact about the three tools comes from its own documentation or repository, checked in October 2026. Tools change, so confirm anything that matters to you before you decide. Where a point is our opinion, the text says so. The links below go to the pages we used.

Ready to find out what is breaking?

Tell us what you’re shipping. We reply by email, and quote each project on its scope.