Why This Choice Matters for Scraping

If the sites you scrape render nothing without JavaScript (infinite scroll feeds, React storefronts, dashboards that arrive as an empty div and hydrate later), you're going to end up driving a real browser. In the Node world that means Puppeteer or Playwright. At first glance they're the same tool. Both speak the Chrome DevTools Protocol, both have a promise-based API, both click, type, screenshot, and intercept requests. Half the code is copy-pasteable between them.

For scraping, though, the differences run deeper than they look. Almost every comparison you'll find online is written from a testing perspective, and test suites never push these tools where scraping does: hundreds of concurrent sessions, anti-bot vendors actively trying to identify you, memory budgets that translate directly into your server bill, and page structures you don't control that change under you without warning.

We run both in production. Here's how we'd make the call today, and why for a large share of workloads the honest answer turns out to be neither.

Same DNA, Different Trajectories

Puppeteer came out of Google's Chrome team in 2017 and became the default choice almost overnight. Its most important legacy for scrapers is the puppeteer-extra plugin ecosystem, which we'll get to.

Playwright launched in 2020 from Microsoft, built by several of the original Puppeteer engineers, which is why the API feels so familiar. They kept the shape and redid the parts that had aged badly: waiting semantics, parallel isolation, single-browser support. Playwright also ships first-party Python, Java, and .NET bindings. Puppeteer is Node-first; the community pyppeteer port has been effectively abandoned for years, and you should not build anything new on it.

Both projects are healthy and actively maintained. This is not a dead-tool-versus-live-tool situation, which is exactly why the decision needs more than a stars-on-GitHub comparison.

Cross-Browser Support

Puppeteer drives Chromium, full stop. (Firefox support technically exists via WebDriver BiDi, but in practice nobody scrapes with it.) Playwright drives Chromium, Firefox, and WebKit through one API, using patched browser builds it downloads itself.

Testing articles treat cross-browser as the headline feature. For scraping it matters for a narrower reason: fingerprint diversity. If every session in your pool presents an identical Chromium fingerprint, you're easy to cluster and block as a group. Mixing Firefox sessions in changes your TLS and JavaScript fingerprint profile, and a fair amount of anti-bot logic targets known headless-Chromium artifacts specifically, so it simply never fires on Firefox. WebKit, on the other hand, is useless for scraping. Its automation fingerprint is rare enough in the wild that it attracts attention rather than deflecting it. It exists for Safari test coverage; leave it there.

One caveat we learned by getting blocked: Playwright's bundled browsers are patched builds, and some anti-bot vendors fingerprint the patches themselves. Pointing Playwright at a real installed Chrome (channel: "chrome") is often quieter than the default bundled Chromium. The same trick applies to Puppeteer.

Auto-Waiting Is the Real Win

Scrapers die from timing bugs. The classic one: the selector existed when your waitForSelector resolved, then the site re-rendered its list 80ms later as data arrived, and your click() hit a detached node. Puppeteer makes all of that your problem to manage:

// Puppeteer: explicit waiting, race conditions are your problem
await page.goto('https://example.com/listings');
await page.waitForSelector('.listing-card', { visible: true });
const prices = await page.$$eval('.listing-card .price',
  els => els.map(el => el.textContent.trim())
);

Playwright's locators re-query the DOM at action time and retry until a timeout:

// Playwright: locators wait and retry automatically
await page.goto('https://example.com/listings');
const prices = await page.locator('.listing-card .price')
  .allTextContents();

On a site that lazy-loads or re-renders as data streams in, the Playwright version just fails less. When we migrated one of our fleets over, the thing that actually improved wasn't speed. It was the retry queue going quiet. A one or two percent drop in flaky failures sounds like rounding error until you multiply it across a hundred thousand pages a day; that's thousands of retries you stop paying for.

Playwright's network tooling is also better across the board: page.route() with glob patterns for interception, page.waitForResponse() for capturing the JSON calls a page makes (frequently the most valuable data on the page), and HAR recording for when you're reverse-engineering a site's internal API.

Contexts, Parallelism, and the Proxy Problem

Scraping economics come down to isolated sessions per gigabyte of RAM. A browser process costs somewhere between 100 and 400MB depending on the site, so one browser per session stops scaling somewhere around hobby size.

Playwright's answer is browser contexts: fully isolated sessions (own cookies, cache, storage) inside a single browser process, created in milliseconds for a few tens of megabytes each:

const browser = await chromium.launch();
// 20 isolated sessions, one browser process
const contexts = await Promise.all(
  Array.from({ length: 20 }, () => browser.newContext({
    proxy: { server: nextProxy() },   // per-context proxy
    userAgent: nextUserAgent(),
  }))
);

Note the per-context proxy. Each session exits through its own IP, which is exactly what a rotating pool needs.

Puppeteer has incognito contexts too, but proxies are set per browser launch, not per context. In practice that means one browser process per proxy, or an external proxy-chain layer doing the routing for you. We ran the external-chain setup for a while and don't recommend it; it's one more moving part, and it's the one that fails at 3am. For proxy-heavy scraping this is the single biggest architectural difference between the two tools, and it's strange how rarely comparison articles mention it.

The Stealth Ecosystem

Here the picture flips, and this is Puppeteer's strongest remaining argument.

puppeteer-extra-plugin-stealth is the most battle-tested anti-detection layer in the ecosystem: dozens of evasions patching navigator.webdriver, the missing chrome.runtime, permission API inconsistencies, WebGL vendor strings, with years of accumulated fixes behind them. playwright-extra ports the same plugin system to Playwright and mostly works, but some evasions assume Puppeteer internals, and fixes have historically landed on the Puppeteer side first.

Before you bet a project on either, some things the tutorials skip. The stealth plugins are themselves fingerprinted; Cloudflare, DataDome, Akamai, and HUMAN all know what a stock stealth setup looks like, so it passes basic checks and routinely fails against top-tier protection. CDP itself is detectable too. The observable side effects of Runtime.enable are a known tell, which is the whole reason the rebrowser patches and hardened forks like Camoufox exist. And no browser plugin fixes your network layer: if your TLS fingerprint or IP reputation gives you away, the request dies before your carefully patched browser ever matters. Our breakdown of TLS fingerprinting and anti-bot detection covers why the connection itself is usually what gets you.

For seriously protected sites, browser choice is one variable among several, and not the biggest one. Our guide on bypassing Cloudflare's anti-bot protection has the fuller picture.

What They Cost to Run

At small scale they cost the same, because Chromium is Chromium and Chromium is what eats your RAM. The differences sit around the edges. Contexts let Playwright pack more isolated sessions into each process, which matters once you're running dozens in parallel. Playwright's browser management is heavier on disk (a full Chromium, Firefox, and WebKit install runs over a gigabyte, which you will notice in your Docker images), while Puppeteer pins a single Chromium build.

The optimization that dwarfs tool choice entirely: block assets. Aborting images, fonts, media, and analytics through request interception typically cuts bandwidth by well over half and speeds up loads dramatically. Both tools do it fine, and skipping this step is the most common waste we see in scrapers people bring to us.

Keep the base ratio in mind too. A browser-rendered page costs on the order of 100 to 1000 times the compute of a plain HTTP fetch. That number should shape your architecture more than anything else in this article.

Head-to-Head

Dimension	Puppeteer	Playwright
Browsers	Chromium (Firefox secondary)	Chromium, Firefox, WebKit
Languages	Node.js	Node.js, Python, Java, .NET
Auto-waiting locators	Manual waits	Built-in, retrying
Browser contexts	Supported, less central	First-class, cheap isolation
Per-context proxy	No (per-launch only)	Yes
Stealth ecosystem	Mature (puppeteer-extra-stealth)	Ported, rougher (playwright-extra)
Network capture	Basic interception	Routes, waitForResponse, HAR
Maintainer	Google Chrome team	Microsoft
Best fit	Stealth-first Chromium scraping	Reliability + parallel scale

Our short version: starting fresh, pick Playwright. The locators, the contexts, and the network tooling pay off every single day you operate. Pick Puppeteer when your workload leans hard on the stealth plugin ecosystem, or when you have Chrome-specific tooling already running that you'd rather not touch. Neither decision is expensive to reverse. The APIs are close enough that we've migrated projects between them in days.

When Neither Is the Right Tool

Now the part most comparisons skip: a lot of browser-automation scraping shouldn't use a browser at all.

Most modern sites render their pages from internal JSON APIs. That listing grid you're driving Playwright across is fed by an XHR call returning clean structured JSON, pagination and IDs included. Find that endpoint (Playwright's network capture is genuinely good for the discovery step) and call it directly, and each page costs a small fraction of a browser render while breaking far less often, because internal APIs change much more slowly than markup.

The catch: default requests or fetch present TLS fingerprints that anti-bot systems flag on the handshake, before any HTML is served. You need a client that impersonates real browser TLS, which is what curl_cffi and tls_client are for. Our decision tree, in order:

1. Static HTML or a discoverable JSON API: HTTP client with browser-grade TLS. Cheapest, fastest, most stable.
2. Rendering genuinely required (content assembled client-side, no clean API, JS-computed anti-bot tokens): Playwright or Puppeteer.
3. Hybrid: a browser establishes the session and harvests cookies and tokens, then an HTTP client does the high-volume fetching with them. Often the best of both.

Teams that default to a browser for everything pay for it, usually something like 10x more infrastructure than the job needs. Spend twenty minutes in the network tab before you write a single page.goto().

Or Skip the Question Entirely

Picking between Playwright and Puppeteer is step one of about twenty. A production scraping operation also needs proxy pools and rotation logic, fingerprint management, CAPTCHA and challenge handling, retry and queueing infrastructure, parsers that survive redesigns, validation, monitoring. All of it maintained continuously, because target sites don't stop changing their defenses just because your scraper works today.

That's the part ScrapeAny takes off your plate. We run the browsers, the HTTP-first pipelines, the anti-bot handling, and the data QA, and hand you clean structured data on your schedule: CSV, JSON, API, or straight into your database. That includes the day your target swaps Cloudflare for DataDome and an in-house scraper would have gone dark mid-quarter.

If your team's core business is using the data rather than fighting for it, that trade is usually worth making.

Get the Data Without the Arms Race

We've made the Playwright-or-Puppeteer-or-no-browser call hundreds of times, and the answer depends on the target, not on ideology. Tell us which sites and fields you need and talk to our team; you'll have a working sample of your data in days, not sprints.