Cypress vs Playwright

Where Playwright wins

Parallelism costs nothing

This is the whole reason the pairing gets searched. The Cypress docs state that running tests in parallel requires the --record flag, which means a Cypress Cloud project and a record key, because the Cloud is what receives the spec list and distributes it. Playwright ships the same capability as two commands: playwright test --shard=1/4 on each machine, then playwright merge-reports to stitch the blob reports into one report. The docs describe this as working on any CI provider without an external service. On the free Cypress tier the difference is sharper than a price: at 500 recorded results a month, hitting the cap disables parallelization outright.

WebKit is a real browser, not an experiment

Playwright downloads and drives patched Chromium, Firefox and WebKit builds itself, so Safari-family coverage is a project you configure rather than a caveat you accept. Cypress runs Chromium-family browsers, Firefox and Electron, with WebKit support still carrying an experimental label. If Safari bugs are the ones reaching your users, that alone can decide it.

Tabs, windows and cross-origin flows stop being workarounds

Cypress documents its own boundaries plainly: it "does not support controlling more than 1 open browser at a time", and each test is "bound to a single superdomain", with cy.origin as the escape hatch. OAuth redirects, payment providers and multi-user chat flows all live on the wrong side of that line. Playwright models browser contexts, pages and origins as ordinary objects, which is why multi-role tests read like normal code there.

The ecosystem momentum is measurable

In the month to 28 July 2026, @playwright/test recorded about 197.2 million npm downloads against 30.5 million for cypress. Treat that as installs rather than teams: CI re-downloads on every run, and other tools pull Playwright in as a dependency. Even discounted, it is the direction third-party integrations are being written for, including Currents, whose dashboard is now Playwright-first.

Where Cypress still wins

The interactive runner has not been rebuilt anywhere. Stepping through a failed run, hovering a command and seeing the DOM as it was at that moment is why plenty of teams write tests at all, and Playwright's trace viewer, good as it is, is a post-mortem rather than a live loop. Cypress is also not standing still: v15.19.0 shipped on 21 July 2026, roughly two weeks after v15.18.1, which is a normal cadence and not the profile of a dying tool.

Cypress Cloud also earns its money in one specific place. It balances specs across machines by measured duration and can cancel a run as soon as a failure makes the rest pointless. Playwright shards split by spec count, so one slow file skews a shard, and nothing cancels the other shards for you. If your suite is uneven and your quota is already paid for, that orchestration is worth something real.

Migrating Cypress to Playwright

The path most teams take:

1. Inventory first. Count custom commands in support/, every cy.intercept alias, and anything reaching into the app through cy.window or cy.stub. Those are the items with no one-line equivalent. There is no official converter, so anything promising a drop-in rewrite deserves suspicion.
2. Change the waiting model, not just the syntax. Selectors and navigation port almost mechanically. What does not is retry-ability: Cypress retries the command chain, Playwright retries the assertion through expect. Ported tests that pass locally and flake in CI are usually this, not infrastructure.
3. Run both for one release cycle. Keep the Cypress suite green while the Playwright one grows, and compare failures rather than counts. Be honest that the overlap period costs double in CI minutes, and on Cypress it still burns recorded test results.
4. What does not move. Your Cypress Cloud run history, flake analytics and screenshots stay behind. Export anything you report on before you cancel the plan, because retention on the free tier is 30 days.