- Where the test code lives decides it, not the syntax
- Who should pick Cypress
- Who should pick Selenium
- Feature by feature
- What the two have in common
- Scenarios that settle it quickly
- How each one fits the stack you already have
- Moving an existing suite across
- Trial both on your own app in a week
- Frequently asked questions
Pick Cypress if you test your own JavaScript web app and want a runner that works inside the browser. Pick Selenium if you need to script real browsers from Java, Python or another of its supported languages, or drive several browsers across a grid. They overlap on end-to-end testing, but they're built very differently underneath.
QA engineers and developers searching this comparison are usually setting up browser tests for a web app, or inheriting a suite and wondering whether to keep it. Both frameworks can click buttons and check what appears on screen. The difference lies in how they talk to the browser, and that shapes almost every decision after it.
Here's how that difference plays out, who each framework suits, and a short trial you can run on your own app.
Where the test code lives decides it, not the syntax
Start with a simple picture. Cypress commands run inside the browser, right beside your app in the same window, and its documentation has a whole page on the trade-offs that come with that choice.
Its makers write the limits down themselves: one test can't control two separate browsers at once, and it isn't a general purpose automation tool. Their advice is that its sweet spot is testing an app your own team builds.
Selenium stands outside and gives instructions. It speaks the official W3C WebDriver standard to Chrome, Firefox, Edge and Safari, and your scripts can be written in Java, Python, C#, Ruby, JavaScript or Kotlin. Standing outside means it isn't tied to one app or one language, which suits teams that don't write JavaScript at all. Once you know which picture suits your situation, the syntax barely matters.
Who should pick Cypress
- Front-end teams writing checks for the product they ship, which its makers call its sweet spot.
- Teams who want a local open-source app for daily work, with a separate cloud product available beside it.
- Projects that never need two browsers in one test (a two-user chat, for example, rules it out).
- Teams already on WebDriver who'd like to try it, since its docs describe a migration path.
Who should pick Selenium
- Back-end or QA groups who'd rather stay in the language they already know, whether that's Java, Python, C#, Ruby or Kotlin.
- Anyone whose customers use a spread of browsers, Safari included, and wants one suite for all of them.
- Projects automating more than one site, or doing browser jobs beyond testing.
- Teams who'll run tests on a Grid, in Docker or in CI, since its documentation covers all three.
Feature by feature
| Cypress | Selenium | |
|---|---|---|
| How it drives the page | Commands run in the browser | Instructions over W3C WebDriver |
| Its own docs say it's for | Testing your own app | Controlling Chrome, Firefox, Edge and Safari |
| Extras | A separate cloud product | Guides for Grid, Docker and CI |
| First-day help | A migration guide from WebDriver | Automatic driver downloads |
Read the rows as a description of two designs, not a scorecard. The top row shapes the rest: a tool that lives inside the page is built around testing one app, and a tool that sends instructions from outside is built around many browsers and many languages.
What the two have in common
Both handle the end-to-end checks most web teams need: log in, fill a form, check the page responds. On the WebDriver side, the tool downloads what it needs to talk to your browser by itself, so there are no drivers to fetch by hand.
Both also come with documentation that's honest about scope. Cypress has a whole trade-offs page listing what it won't do, and Selenium's documentation sets out how to run tests on a Grid, in Docker or in CI. Read both before your trial; they answer most early questions faster than a forum thread will.
If you're also looking at a newer framework, Selenium vs Playwright is worth reading next.
Scenarios that settle it quickly
If your journeys include two users chatting or one person's action showing up on another's screen, the in-browser runner's own docs rule it out, because it can't drive two browsers at once.
If Safari is part of your audience, Selenium covers it, along with the other major browsers named on its home page.
If your testers write Python or Java all day, the WebDriver route lets them stay there, while the in-browser runner is built around your own JavaScript app.
If you also automate jobs on other people's sites, remember the in-browser runner says it isn't a general purpose automation tool.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
If the suite only ever checks the product your team ships, you're in what Cypress calls its sweet spot.
How each one fits the stack you already have
Cypress splits into two pieces. Its open-source app is where tests are written and run day to day, and a separate cloud product sits beside it. You can start with the app alone and decide later whether the cloud side earns a place, so ask what the cloud product adds before you plan around it.
The WebDriver option meets teams where they already are. Java, Python, C#, Ruby, JavaScript and Kotlin are all on its list, so a QA group can write tests in the language their back-end colleagues review every day. That matters when developers are expected to fix the tests they break: a suite in their own language is one they'll open without being asked.
Moving an existing suite across
If you already have WebDriver tests and the in-browser model appeals, the in-browser framework's documentation includes a migration guide. Treat it as a project, not a weekend job. Start with the tests that break most often, since those show you quickly whether the new approach is calmer, and leave the stable ones alone until you're sure.
Going the other way usually happens when a team needs more browsers, more languages or two-browser scenarios. In that case, rewrite the scenarios that forced the move first, and keep the rest running where they are while you learn.
Trial both on your own app in a week
- Pick three journeys that matter: sign-in, one form, and one page with dynamic content.
- Build that trio in both tools, using whichever language your developers are most at home in.
- Add a test that needs a second browser or a second tab, and see which setup copes.
- Run the suite on every browser your customers use, and note gaps.
- Put both into your CI pipeline and see how long setup takes.
- Break something on purpose and compare how quickly each one helps you find the cause.
- Ask the person who'll maintain the suite which one they'd rather open on a Monday morning, and give their answer real weight.
Keep both suites running in CI until the new one has caught a real bug. That's the moment you know it earns its place.
Frequently asked questions
Do I need the cloud product to get started?
The open-source app and the cloud service are separate products, so you can start with the app and check the vendor page for what the cloud side adds.
Which is easier for a beginner to pick up?
It depends on the language they already know. Start with the tool whose tests they can read on day one.
Can I write WebDriver tests in Kotlin?
Yes. Kotlin is one of the six languages Selenium's home page lists for writing scripts.
Do I need Docker to run WebDriver tests?
Not necessarily. Docker is one setup its documentation covers, alongside Grid and CI, so pick whichever fits how you already run builds.
What is W3C WebDriver?
The official web standard these scripts use to drive a browser. Check that every browser you need appears in its docs.
