Cypress and Selenium both automate a browser to test a web app, but they were built on opposite philosophies. Selenium is a language-agnostic standard that drives any browser from the outside. Cypress is a JavaScript-first tool that runs inside the browser alongside your app. That one architectural choice explains almost every difference that follows.
The core architectural difference#
Selenium talks to the browser through the WebDriver protocol, a W3C standard. Your test code sends commands over HTTP to a browser-specific driver (chromedriver, geckodriver), which executes them in a real browser. The test process and the browser are separate, which is why Selenium can drive any browser in any language but also why you spend so much time managing waits and synchronization.
Cypress runs in the same event loop as your application. The test code executes inside the browser, next to the app under test, with no network hop per command. That proximity is what gives Cypress its automatic waiting, time-travel debugging, and direct access to the DOM and network layer. It is also what historically constrained it: anything outside that single browser context was hard.
Side by side#
| Dimension | Cypress | Selenium |
|---|---|---|
| Languages | JavaScript and TypeScript only | Java, Python, C#, Ruby, JavaScript, and more |
| Architecture | Runs inside the browser | Drives the browser via WebDriver over HTTP |
| Browser coverage | Chromium family, Firefox, experimental WebKit | Chrome, Firefox, Safari, Edge, and others |
| Waiting | Automatic, built in | Mostly manual (explicit and implicit waits) |
| Setup | One npm install, batteries included | Wire up driver, bindings, and often a test runner |
| Debugging | Time-travel snapshots, runs in the browser | Logs and screenshots, external debugger |
| Parallel / scale | Cypress Cloud or CI sharding | Selenium Grid (mature, self-hostable) |
| Best known for | Developer experience | Cross-browser, cross-language reach |
Where Cypress wins#
The developer experience is the headline. npm install cypress gets you a runner, assertions, and a browser, with no separate driver to manage. Commands wait for elements automatically, which removes the single biggest source of Selenium flakiness. When a test fails, the time-travel view lets you step back through each command and see the exact DOM state at that moment. For a team writing tests in JavaScript or TypeScript against a modern single-page app, Cypress is usually faster to get productive in.
It also does component testing, so you can test a React or Vue component in isolation with the same tool you use for end-to-end runs.
Where Selenium wins#
Reach. Selenium speaks many languages, so a Java or Python team is not forced onto JavaScript. It drives every major browser including Safari, which matters if you have to certify against the real thing. And Selenium Grid is a mature, self-hostable way to fan tests out across a large matrix of browsers and machines, which is why it underpins most device-farm and cross-browser cloud services. Appium, the standard for mobile automation, is built on the same WebDriver foundation.
If your constraints are "must run in our existing language" or "must cover this exact browser and OS matrix at scale," Selenium is often the only one of the two that qualifies.
Cypress limitations to know about#
Cypress has closed some historical gaps but not all of them. Multi-origin flows are supported through cy.origin, but they are more awkward than in a tool built for them. There is no real multi-tab support, by design. WebKit (Safari) support is still experimental. And because tests run in the browser, scenarios that need to step outside it are harder. None of these are dealbreakers for most app testing, but they are worth checking against your real flows before you commit.
The option most teams now also weigh: Playwright#
Any honest 2026 comparison has to mention Playwright. It keeps much of Cypress's developer experience (auto-waiting, a clean API, good debugging) while supporting multiple languages, true multi-tab and multi-origin, and all three engines including WebKit, without the WebDriver overhead. For new suites, the real decision is often Cypress vs Playwright, with Selenium reserved for the cross-language and grid-scale cases it still owns.
So which should you pick?#
- Modern JS/TS front-end team, want speed and great DX: Cypress (or Playwright).
- Multiple languages, broad browser and device matrix, grid at scale: Selenium.
- Greenfield suite and you want the widest capability with good DX: look hard at Playwright before deciding.
Whichever you choose, the long-term cost is not writing the first tests, it is keeping them green as the UI changes. That maintenance is where AI test tools now help: ObserveOne's Autopilot generates Playwright suites from a URL and self-heals selectors when the app shifts, so the suite survives redesigns instead of rotting. If you have already settled on a framework, the complete Playwright guide is a good next read.