Architecture: direct protocol vs WebDriver
The core difference is how each library talks to the browser. Playwright connects to the browser over a single persistent WebSocket, using the Chrome DevTools Protocol (CDP) for Chromium, a patched Marionette/Juggler channel for Firefox, and the WebKit inspector protocol for WebKit. This direct, low-latency control lets one connection both send commands and stream events (network, console, DOM lifecycle).
Selenium instead implements the W3C WebDriver standard. Your code talks to a language binding, which sends HTTP/JSON commands to a separate driver process (chromedriver, geckodriver, etc.), which in turn drives the browser. That extra hop is what historically made Selenium feel slower and more request-oriented. Selenium 4 added WebDriver BiDi, a bidirectional protocol that brings event streaming (network interception, console logs, live DOM events) much closer to what CDP offers, and ongoing BiDi work is narrowing the architectural gap. The tradeoff is real: WebDriver is a cross-browser W3C standard with the widest official browser support, while Playwright's tighter coupling to each engine is what enables its richest features.
Speed, flakiness, and the auto-wait model
Playwright's biggest practical advantage is built-in auto-waiting. Before an action like page.click(), it automatically waits for the element to be attached, visible, stable (not animating), enabled, and able to receive events. This removes a whole class of timing bugs and means you rarely write manual sleeps.
Selenium does not track real-time DOM state for you. You manage timing explicitly with WebDriverWait and expected_conditions, polling the DOM on an interval (commonly 500 ms). If a condition becomes true between polls, you wait for the next tick, which is a common source of flaky tests on slower CI machines. Teams migrating to Playwright frequently report large reductions in flaky failures, mostly attributed to auto-waiting.
- Parallelism: Playwright isolates each test in a lightweight browser context inside one browser process, so a single machine can run many parallel sessions cheaply. Selenium scales out with Selenium Grid, distributing sessions across nodes, which is heavier but battle-tested at large scale.
- Setup: Playwright bundles and version-matches its browsers via
playwright install. Selenium relies on separate drivers, though Selenium Manager now auto-resolves driver/browser versions, closing a long-standing pain point. - Maturity: Selenium has the longer track record, larger community, and deeper integration with legacy CI, cloud grids, and enterprise tooling.
Detection surface and scraping considerations
For data collection, both tools drive a genuine browser, so they execute JavaScript, render dynamic pages, and expose the same DOM. A frequently misunderstood point: both Playwright and Selenium set navigator.webdriver to true by default, because that property is defined by the W3C WebDriver specification, not unique to Selenium. Sites that fingerprint browsers can read this and other automation signals (consistent viewport, missing or default headers, headless rendering quirks) regardless of which library you use.
Practically, this means your library choice rarely changes whether automated traffic looks automated; configuration and runtime environment do. The launch argument --disable-blink-features=AutomationControlled, along with header and locale configuration and the choice of headless versus headed mode, controls some of these signals, which is why runtime configuration matters more than library choice. Maintaining that surface across many sites, plus rotating proxies and handling retries, is a meaningful amount of infrastructure. A managed web-data API such as Scrappey can fold the browser session, proxy rotation, and retry logic into a single request when you would rather not operate that stack yourself, while Playwright or Selenium remain the right call when you need full local control of the browser.