Selenium vs Playwright: Key Differences, Code Compared and Which to Choose

If you are starting a test automation project, the Selenium vs Playwright question will come up quickly. Search results can make it sound like a settled matter, but the right answer depends on your team, your existing tests and the browsers you must support.

This guide compares them on the things you will actually feel in daily work. The code samples show the typical style of each tool, and we did not run them for this article. We also avoid quoting speed percentages, because published benchmarks vary widely and often come from vendors. Measure on your own application if speed will decide the matter.

The short answer

Choose Playwright for most new web testing projects, particularly if your team can work in JavaScript, TypeScript, Python, Java or .NET. You get more features out of the box, and less time goes on infrastructure and flaky waits.

Choose Selenium if you already have a large, working suite, if you need a language Playwright does not officially support such as Ruby, or if you must test on the real browser builds and platforms available through a Selenium grid or device cloud.

Selenium vs Playwright side by side

Architecture: how each one talks to the browser

Selenium sends commands using the W3C WebDriver protocol, a formal standard. Your code talks to a driver, such as ChromeDriver, which controls the browser, with each command usually being a separate HTTP request. Because browser vendors support this standard, it has broad compatibility. A newer protocol, WebDriver BiDi, is adding two-way communication and event streaming to the standard.

Playwright keeps a persistent connection to the browser and uses its own patched builds of Chromium, Firefox and WebKit. Because the connection is direct and two-way, it can react to browser events, and each test can run in its own lightweight browser context. This is why most comparisons rate Playwright as faster, though the actual gap depends on your application and your tests.

One test in both tools

Here is the same login test, written in Python, against a public practice site.

Selenium

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def test_login(driver):
    driver.get("https://the-internet.herokuapp.com/login")
    driver.find_element(By.ID, "username").send_keys("tomsmith")
    driver.find_element(By.ID, "password").send_keys("SuperSecretPassword!")
    driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()

    message = WebDriverWait(driver, 10).until(
        EC.visibility_of_element_located((By.ID, "flash"))
    )
    assert "You logged into a secure area" in message.text

You also need a fixture to create and close the driver, as we show in our Selenium Python tutorial.

Playwright

from playwright.sync_api import Page, expect

def test_login(page: Page):
    page.goto("https://the-internet.herokuapp.com/login")
    page.get_by_label("Username").fill("tomsmith")
    page.get_by_label("Password").fill("SuperSecretPassword!")
    page.get_by_role("button", name="Login").click()

    expect(page.locator("#flash")).to_contain_text("You logged into a secure area")

This relies on the pytest-playwright plugin, which supplies the page fixture. It is shorter, mainly because the wait is built into expect, and because locators like get_by_role describe the page the way a user sees it. With Selenium, you can reduce this boilerplate considerably with helpers and the Page Object Model, which we recommend in either tool.

Waiting and flaky tests

Timing is the top cause of flaky browser tests, and it is where the two tools differ most in everyday use.

In Selenium, you are responsible for synchronisation. Explicit waits work well, but somebody has to remember them everywhere, and teams that forget often fall back on time.sleep. Our guide to Selenium waits explains how to do this correctly.

In Playwright, actions automatically check that an element is visible, stable, enabled and able to receive events before acting. Web-first assertions keep retrying until a timeout. You still can write flaky tests, for example with poor test data, but a major source of problems is handled by default.

Browsers and languages

This is where Selenium keeps a real advantage. Playwright’s WebKit build is close to Safari’s engine, but it is not the same thing as Safari on a Mac or iPhone. If real Safari behaviour is critical, Selenium with SafariDriver, or a real device cloud, gets you closer to what your users actually run.

Similarly, Playwright tests its bundled browser versions, though it can also drive installed Chrome and Edge channels. Selenium drives the browsers you install, which helps if you must support specific versions. For native mobile apps, neither is the full answer: Appium, which is built on WebDriver concepts, is the usual tool.

On languages, Selenium officially supports Ruby and has a very long history in Java teams. Playwright’s Node.js version also has the most complete tooling, since the full test runner is there. Other languages get the core library and integrate with their own test frameworks.

Debugging

Playwright has a clear lead here. Its trace viewer records each action, along with DOM snapshots, network calls and console logs, so you can step through a failed CI run after it has finished. Its UI mode and codegen help you write tests faster as well. See our Playwright tutorial for beginners for how to use them.

With Selenium, you assemble this yourself, from screenshots on failure, browser logs, video from your grid provider and reports from your test framework. It works well, and many teams have excellent setups, but it takes effort to build.

Network and API features

Playwright can intercept and mock network requests with a few lines of code, which is useful for testing error states:

page.route("**/api/orders", lambda route: route.fulfill(status=500))

It also includes an API request client, so you can create test data through an API before driving the browser. Selenium 4 has added some network features through the Chrome DevTools Protocol and BiDi, but support and convenience vary by browser and language. Many Selenium users add a proxy or a separate HTTP library, as in API testing tools.

Parallel runs and scale

Playwright’s runner handles parallel workers and sharding across CI machines with simple options. Browser contexts are cheap, so isolation does not require a whole new browser for every test.

Selenium uses Selenium Grid to distribute tests across machines and browser versions, and test frameworks handle the parallelism. Grid is more to run, but it is proven at very large scale, and many commercial device clouds support it directly.

Should you migrate from Selenium to Playwright?

Not automatically. A working suite is valuable, and a rewrite takes time away from testing the product. Ask these questions first:

1. Is there a measurable problem? Flaky tests or slow debugging are good reasons. “It is newer” is not.
2. How big is the suite? A hundred tests can be moved. Ten thousand is a major project.
3. Are your page objects clean? Good abstractions make the move far cheaper.
4. Do you rely on Selenium-specific features? Check your grid and device needs first.

If you do move, go gradually. Write new tests in Playwright, migrate the flakiest old tests first, and run both side by side until the old suite is small enough to retire. Do not translate tests line by line, since that carries over sleeps and old locators. Avoid the mistakes covered in test automation mistakes as well.

How to choose

Best of all, run a short pilot. Automate your three most awkward journeys in each tool against your own application, in your own CI, and compare the code, the speed and how easily you can debug a failure. One week of evidence beats any comparison article, including this one. If Cypress is also on your shortlist, read Playwright vs Cypress.

Final thoughts

Playwright is usually the easier place to start, and Selenium remains a dependable standard with a broad reach. Neither will save a poorly designed test suite. Choose based on your real constraints, invest in stable locators and good test data, and keep your suite focused on what matters most to your users.

Frequently asked questions

Keep learning