Playwright vs Puppeteer for testing and scraping

Playwright vs Puppeteer is a question about two jobs: testing and scraping. We use Playwright for end-to-end tests and website audits. The same tool also fits scraping pages that need a real browser. For new work we would pick Playwright, unless you only drive Chrome from a Node script and already have working Puppeteer code.

Honest limit first: Puppeteer appears in exactly one old project of ours, and we never ran the two side by side. So this article does not benchmark them. It shows what we run, why one tool was enough, and the decision that matters more in scraping: whether you need a browser at all.

What is the difference between Playwright and Puppeteer?

Both drive a real browser from code. They differ in reach. Puppeteer is "a JavaScript library which provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi" (pptr.dev, retrieved 2026-10-24). Playwright "supports Chromium, WebKit and Firefox on Windows, Linux and macOS" (playwright.dev, retrieved 2026-10-24).

Sources for the table: the pages above and Playwright's migration guide from Puppeteer, all retrieved 2026-10-24.

The row that decided it for us is the test runner. One library that gives us both the browser and the test runner means one tool to learn, one browser install in CI and one set of selectors.

How do we use Playwright for testing?

In three places, from strict to loose.

End-to-end tests. Our starter template runs Playwright Test against the dev server. The config, shortened:

// playwright.config.ts
import { defineConfig } from '@playwright/test'

export default defineConfig({
  testDir: './e2e',
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  use: { baseURL: 'http://localhost:3001', trace: 'on-first-retry' },
  projects: [{ name: 'chromium', use: { browserName: 'chromium' } }],
  webServer: { command: 'bun run dev', url: 'http://localhost:3001', reuseExistingServer: !process.env.CI },
})

And one of the specs:

test('dashboard redirects to login when not authenticated', async ({ page }) => {
  await page.goto('/dashboard')
  await expect(page).toHaveURL(/login/)
})

No sleeps, no manual waits. expect(page).toHaveURL retries until it passes or times out. That is the part you would write by hand in Puppeteer.

Website audits. When we audited this site, the checks were plain Playwright scripts: text contrast from computed colours, axe accessibility rules, layout at phone width, load under CPU throttling. Throwaway scripts, not a test suite.

The AI agent checking its own change. The agent opens the app through Playwright MCP and reports what it saw. How that works is in Playwright MCP: let the AI agent prove it works.

How is Playwright used for scraping?

Through Crawlee, which wraps both libraries. As its docs put it, "Crawlee comes with three main crawler classes: CheerioCrawler, PuppeteerCrawler and PlaywrightCrawler" (crawlee.dev, retrieved 2026-10-24). Swapping Puppeteer for Playwright there is mostly a class name. The real choice is the first class: HTTP or browser.

For a JavaScript-heavy page, PlaywrightCrawler fits. A simplified example:

import { PlaywrightCrawler } from 'crawlee'
import { router } from './routes.js'

const crawler = new PlaywrightCrawler({
  maxRequestsPerCrawl,
  requestHandlerTimeoutSecs: 360,
  navigationTimeoutSecs: 60,
  maxRequestRetries: 4,
  requestHandler: router,
  launchContext: {
    launchOptions: { args: ['--disable-gpu'] }, // GPU crashes in Docker
  },
})

await crawler.run(startUrls)

If the data is in the HTML, you need no browser at all. CheerioCrawler reads sitemaps and product pages.

How to decide, per page type:

The last step matters most. No library saves a crawler that stops quietly, only an alert does. More in Crawlee for web scraping: what breaks in production.

Why did we never need Puppeteer?

Because every job we had was covered once Playwright was in the repository. Tests needed a runner, Playwright has one. A second browser library would have added an install, not a capability.

That line comes from the Playwright team, so read it as a vendor's view. For Chrome-only work, Puppeteer remains a sound choice.

When would Puppeteer be the better pick?

From what the docs say, not from our runs:

• You only need Chrome, from a Node script, and you already have Puppeteer code that works. Rewriting it gains little.
• You work close to the Chrome DevTools Protocol and want a library built around it.
• Your tests run in another framework already, and you only need a browser driver, not a runner.

If you also need WebKit, Python, or a test runner in the same tool, Playwright covers it. Playwright says most Puppeteer APIs "can be used as is" in a migration (guide), so the switch is usually small.

Playwright or Puppeteer: which one for your project?

Answer these before you choose. Each "yes" points to Playwright:

Need tests or a crawler that hold up in production?

If you regularly need data the source allows you to collect, we build you collection with monitoring that alerts you when it stops working. We do it as part of business process automation. AI writes most of our code. A senior reviews every change and is accountable for production. Since 2023 we have delivered 15+ production projects.

We get back to you within two business days with a few questions about your work. Then we agree on what we do first.

If you'd rather talk first, book a 15-minute intro call.

Which of your pages really need a browser?

Frequently asked questions

What is the difference between Playwright and Puppeteer?

Puppeteer is a JavaScript library for Chrome and Firefox. Playwright drives Chromium, WebKit and Firefox, has bindings for JavaScript, Python, Java and .NET, and ships its own test runner with auto-waiting locators. For new work that needs tests or more than one browser, Playwright covers more.

Is Playwright better than Puppeteer for web scraping?

For scraping, the library matters less than whether you need a browser at all. Most public pages are plain HTML, and an HTTP crawler with Cheerio is enough. Only JavaScript-rendered pages need a real browser, and there Playwright through Crawlee fits. We have not benchmarked Puppeteer against it.

Can I migrate from Puppeteer to Playwright?

Yes. Playwright publishes a migration guide and says most Puppeteer APIs can be used as is. The bigger change is moving from element handles and manual waits to locators and web-first assertions.

Does Puppeteer support Firefox and Safari?

Puppeteer controls Chrome or Firefox over the DevTools Protocol or WebDriver BiDi. It does not drive WebKit, so testing Safari behaviour needs Playwright or another tool.

Do I need a headless browser for web scraping?

Often not. If the data is in the HTML the server returns, an HTTP request plus an HTML parser is faster and cheaper to run. Use a browser only for pages that render data with JavaScript.