Playwright vs Puppeteer vs Selenium: browser automation for scraping

Playwright, Puppeteer, and Selenium all drive a real browser. They differ in browser coverage, language support, waiting model, and ecosystem maturity. The right choice depends on which browsers you must test, which language your team uses, and how much of the browser lifecycle you want the library to manage.

At a glance

Browser coverage

Playwright bundles its own browser builds for Chromium, Firefox, and WebKit. That gives consistent behaviour across engines, at the cost of downloading three browsers. Puppeteer is Chromium-first; it can drive Firefox through WebDriver BiDi, but Chromium is the primary target. Selenium drives browsers through their own drivers (chromedriver, geckodriver, etc.), which is flexible and matches the browser versions you install, but version alignment is part of the operational work.

For scraping, Chromium is usually enough. If you need to verify how a page behaves in Safari/WebKit, Playwright is the shortest path.

Waiting model

Playwright’s locators auto-wait for elements to be attached, visible, and stable before acting. That removes many explicit sleeps, but it does not read your mind: waiting for the wrong element still times out.

Puppeteer has waitForSelector and related methods; it does not auto-wait as aggressively. You write the wait for the condition you need.

Selenium’s WebDriverWait is explicit and powerful, but verbose. A missing wait shows up as a NoSuchElementException or a stale element reference.

In all three, the rule is the same: wait for a fact (an element, a response, a URL), not for a fixed number of seconds.

Network control

Playwright and Puppeteer expose request interception: block images, stub responses, inspect headers. That is useful for speed and for understanding which request returns the data. Selenium can use a proxy or the browser’s performance logs, but request interception is less direct and driver-dependent.

For scraping, interception is often the fastest way to discover the JSON endpoint behind a page. If the endpoint is public and permitted, fetch it directly and skip the browser.

Operational cost

All three run a browser, so all three pay the memory and CPU cost described in the headless browsers guide. Differences:

• Playwright downloads browser binaries per version; upgrades are explicit. The trace viewer is excellent for debugging a failed run.
• Puppeteer tracks Chrome closely; the bundled Chromium version changes with the package. It is lightweight for Node-only stacks.
• Selenium requires a driver per browser and careful version alignment. Selenium Grid is mature for distributed execution, but it is more infrastructure.

When to choose Playwright

• You need Chromium, Firefox, and WebKit with one API.
• You want auto-waiting locators and a trace viewer.
• You use Python, Java, .NET, or TypeScript.
• You need request interception and multiple contexts.

When to choose Puppeteer

• You are in Node.js and only need Chromium.
• You want a small dependency and direct access to Chrome DevTools Protocol.
• You already use Chrome-specific features.

When to choose Selenium

• You need a language not covered by the others (for example, Ruby).
• You already run Selenium Grid.
• You need to drive a real installed browser/version for compatibility testing.
• Your organisation standardises on WebDriver.

When none of them is the right tool

If the page returns its data in HTML or a JSON endpoint, use an HTTP client. A browser is the most expensive way to fetch a page, and it does not grant permission to access a login, paywall, or CAPTCHA. The static vs JavaScript lesson explains the decision.

Sources

• Playwright documentation
• Puppeteer documentation
• Selenium documentation