Short answer: Playwright and Cypress both do the same job: drive a real browser through your web app and assert what happens. Where they differ is in how they do it. Playwright controls the browser from outside, in any of four languages, across Chromium, Firefox and WebKit, with parallel runs built in for free. Cypress runs inside the browser alongside your app, in JavaScript only, with a developer experience many people prefer and a paid cloud service for parallelisation. In 2026 Playwright is the default choice for new projects. Cypress is still the better fit for some teams, and we'll say which.
The short version
| Playwright | Cypress | |
|---|---|---|
| Latest stable (Oct 2026) | 1.63.0 (4 Sep 2026) | 16.1.1 (29 Sep 2026) |
| Maintainer / licence | Microsoft, Apache-2.0 | Cypress.io, MIT |
| Languages | JavaScript/TypeScript, Python, Java, .NET | JavaScript/TypeScript only |
| Browsers | Chromium, Firefox, WebKit, branded Chrome and Edge | Chrome family, Edge, Firefox; WebKit experimental; Electron deprecated |
| Where tests run | Outside the browser, driving it over a protocol | Inside the browser, in the same run loop as the app |
| Multiple tabs / origins | Supported | One browser at a time; cross-origin via cy.origin |
| Parallel runs | Built in, free (--workers, --shard) | Needs Cypress Cloud or a third-party tool |
| Debugging | Trace Viewer, UI Mode, codegen | Time-travel command log, Cypress Studio (beta) |
| Weekly npm downloads (w/e 29 Sep 2026) | 78.5M (@playwright/test) | 7.2M (cypress) |
| GitHub stars (1 Oct 2026) | 96.9k | 51.0k |
Sources for every row are at the end of this article.
Architecture, and why it decides most of the other rows
Cypress's own docs say it plainly: Cypress is executed in the same run loop as your application. Your test code runs in the browser next to the app, with direct access to window, the DOM and the app's state, while a Node process on the side handles anything that needs higher privileges. That design is why Cypress feels so immediate when you're writing a test. It's also why it can only ever be JavaScript, why it can't control more than one browser at a time, and why every test is bound to a single superdomain unless you reach for cy.origin.
Playwright sits outside the browser and drives it. It ships its own patched builds of Firefox and WebKit, which is why it doesn't work with branded Safari, and it gives you browser contexts, isolated incognito-style profiles that can be opened several at a time in one test. If you need to test two users chatting to each other, or a checkout that bounces through a payment provider on another origin, that's the architectural difference that matters.
Browsers
Playwright covers Chromium, Firefox and WebKit, plus branded Chrome and Edge channels including beta, dev and canary. Its WebKit is built from WebKit's main branch, which means it often has features before Safari does and is not the same thing as testing in Safari.
Cypress supports the latest three major versions of Chrome, Edge and Firefox, plus Chromium. WebKit support is experimental, requires a flag, and installs Playwright's own playwright-webkit package underneath. The bundled Electron browser is deprecated and slated for removal.
If Safari coverage is a hard requirement, neither tool gives you real Safari. See the section on mobile below.
Languages
Playwright has first-party bindings for JavaScript/TypeScript, Python, Java and .NET, and the docs claim all core browser-automation features work in all four.
Cypress is JavaScript and TypeScript. The trade-offs page states it as policy: the only language we'll ever support is the language of the web: JavaScript. For a frontend team that's fine. For a Python or .NET shop that wants the test code next to the backend, it's a non-starter.
Parallel runs, and what they cost
Playwright's runner executes tests in worker processes out of the box, and splits a suite across CI machines with --shard, merging the reports afterwards. There's nothing to sign up for and nothing to pay.
Cypress's native parallelisation requires the --record flag and a Cypress Cloud project. Cypress Cloud's free tier covers 500 test results a month, the Team tier is listed at $67 a month, or $799 a year on the annual plan, with 120,000 test results a year, and overages on Team are billed at $6 per thousand results. Those figures were read on 1 October 2026 and pricing pages change, so verify before you quote them to your finance team. Two open-source workarounds exist: cypress-split, which splits spec files across CI machines with no external service, and sorry-cypress, a self-hosted replacement for the dashboard.
A note on what "500 test results" means: it's individual test results, not runs. A 200-test suite run three times a day is over that allowance on day one.
Component testing
Both support it. Playwright reworked component testing in 2026 into a stable, framework-agnostic model: the experimental @playwright/experimental-ct-* packages have been removed, and the docs now describe a mount fixture that works with React, Vue, Svelte, Solid or anything your dev server can render. Older comparison articles still call Playwright's component testing experimental; that's out of date.
Cypress has dedicated component-testing support for React, Angular, Vue and Svelte. Cypress 16 raised the minimum versions (Angular 21, Vite 8) and dropped Next.js 14 (changelog), so check your framework versions before upgrading.
Debugging and authoring
Cypress's strongest card has always been the time-travel command log: hover a command and the app snaps back to the state it was in when that command ran. Cypress Studio, in beta, records clicks into Cypress commands without a Cloud account; the AI suggestions on top of it need Cloud.
Playwright's answer is the Trace Viewer, which records actions, DOM snapshots, network, console and source for a run and lets you step through it after the fact, including for runs that happened in CI. UI Mode gives you a watch-mode runner with the same time-travel feel, and codegen records interactions into test code, favouring role and text locators over brittle CSS selectors.
On authoring, 2025 and 2026 pulled the two apart. Playwright 1.56 added test agents, a planner that explores the app and writes a Markdown test plan, a generator that turns the plan into tests, and a healer that re-runs failures and attempts repairs, all driven from Claude Code, Codex or VS Code. There's also a separate Playwright MCP server for coding agents. Cypress has been building the same kind of agent tooling on the Cloud side, an MCP server and a cypress tap CLI, both tied to Cypress Cloud; the Cypress blog has the current state.
Mobile and Safari
Playwright ships device descriptors for phones and tablets: viewport, user agent, pixel density, touch. Run an iPhone descriptor under the WebKit project and you get a WebKit engine at an iPhone viewport, which is closer to Safari than Chromium is but is still not Safari. Cypress can set a viewport and a user agent but has no WebKit outside the experimental flag above. For real iOS Safari, both tools hand off to a real-device cloud or a Mac with Xcode. For the foldable, see how to test your website on iPhone Duo.
Who should pick which
Pick Cypress if your team is JavaScript-only, lives in the browser, values the in-browser debugging loop above everything else, and your suite is small enough that Cypress Cloud's pricing is a rounding error or you're happy running cypress-split. Plenty of frontend teams are in that position and are happier on Cypress.
Pick Playwright if you need more than one language, more than one browser engine, multi-tab or multi-origin flows, or parallel runs without a bill attached. It is also where the ecosystem's attention is: the download gap (78.5 million weekly for @playwright/test against 7.2 million for cypress, npm, week ending 29 September 2026) tells you where new tooling, agents and integrations will land first.
The decision that matters more than the framework
The framework question is the one teams spend a week on. The one that decides whether the suite is still alive in two years is how big you let it get, and on that both tools are equally dangerous.
Every Playwright test and every Cypress test is a script written against the UI as it looked on the day it was written. The product changes, the script doesn't, and someone pays the difference in maintenance. That's true at ten tests and it's true at a thousand, and the teams we see struggling aren't the ones who picked the wrong framework. They're the ones who let a scripted suite grow until a run takes an hour, a flake rate of a percent or two guarantees a red on every build, and nobody can say what green means any more. We've written up why a large regression suite is a liability, with the numbers; the short version is that past a certain size the suite stops being a signal and becomes a cost centre nobody dares delete from.
So pick Playwright or Cypress on the criteria above, and then keep the suite you build in it small. Somewhere between 50 and 200 scripted test cases covering the flows that must never break: sign-up, login, payment, the two or three things the product exists to do. Scripts are the right tool for those, because you want them run the same way every time, and if you already have a few thousand working Playwright tests, keep them.
Everything else is where the model is shifting. On every pull request, something has to work out what the change can affect, generate test cases for that, run them against the preview build, and report. Scoped to the diff, run once, and generated again next time from next time's diff, so there's no script to maintain and no reason to re-run the sign-up flow because someone touched the invoice export. We call that dynamic testing, and it's the half of the strategy that neither framework can give you, because both of them produce static scripts by design. It won't catch everything; nothing diff-scoped finds a side effect buried in a stored procedure three services away. What it removes is the reason to keep growing the scripted suite. QA.tech, an agentic testing platform, is built for that second half and leaves your Playwright or Cypress suite alone.
If you take one thing from this comparison: the download gap tells you where the tooling is going, but the maintenance gap tells you where your evenings are going. Choose the framework that fits your team, and choose a suite size you can still trust next year.
Frequently asked questions
Is Playwright better than Cypress? For most new projects in 2026, yes, on reach: more languages, more browser engines, multi-origin support and free parallelisation. Cypress remains the better developer experience for JavaScript teams who prize its in-browser debugging, and "better" depends on which of those you weigh more.
Is Cypress free? The Cypress test runner is open source under MIT and free to use. Native parallelisation and the dashboard features require Cypress Cloud, which has a free tier capped at 500 test results a month and paid tiers above that. Open-source alternatives such as cypress-split and sorry-cypress exist.
Can Cypress test in Safari? Not in real Safari. Cypress has experimental WebKit support behind a flag, which installs Playwright's WebKit build. Playwright's WebKit is also not Safari. For real Safari you need a real device or a Mac running Safari.
Can I migrate from Cypress to Playwright?
Yes, and it's common, but budget for a rewrite. The command model (cy.get().should() versus await expect(locator)) and the async model are different enough that automated converters produce code you'll want to rewrite anyway. Migrate the critical-path tests first and let the rest lapse if nobody misses them.
Which one runs faster? On a single test, neither has an edge worth choosing on. The wall-clock difference on a suite comes from parallelism, which Playwright runs in worker processes for free and Cypress ties to a Cloud plan. Measure on your own suite before deciding on speed alone.