Playwright vs Puppeteer: Which Browser Automation Library?

Both libraries do the same core thing: script a real browser from Node. They came from overlapping lineages, and the core APIs look similar enough that porting between them is mechanical. The differences that matter show up once you are running a suite rather than a script.

The short version

Where the real difference is

Auto-waiting. This is the one that changes day-to-day life. Playwright waits for an element to be attached, visible, stable and able to receive events before it acts. Puppeteer generally expects you to say when to wait.

The consequence is not convenience, it is flakiness. Most flaky browser tests are timing assumptions that hold on a fast machine and break in CI. A library that waits by default removes a whole category of them before you write anything. If you have inherited a Puppeteer suite that fails intermittently, a large share of those failures are usually this.

Cross-engine coverage. Playwright drives WebKit, which is the practical way to catch Safari-specific problems without owning Apple hardware. Puppeteer's coverage is narrower.

Whether this matters depends entirely on your users. If your analytics say a meaningful share arrive on iOS Safari, it is decisive. If you are building an internal tool that only ever runs in Chrome, it is worth nothing and you should not pay for it in complexity.

The test runner. Playwright ships one, with parallelism, fixtures, retries, sharding and reporters. Puppeteer is a library, so you bring Jest or Mocha and assemble the rest.

For a handful of scripts, assembling your own is fine and arguably cleaner. For a suite that a team maintains, the assembled version is a pile of decisions each of which can rot, and the bundled runner is the pragmatic choice.

Debugging. Playwright's trace viewer records a timeline with DOM snapshots, network activity and screenshots per step. When a test fails only in CI, that recording is often the difference between a fix and an afternoon.

When Puppeteer is still the right call

Chromium-only automation that is not testing. Scraping, PDF generation, screenshots, driving a headless browser as part of a pipeline. Puppeteer is a smaller thing to learn and the extra surface area of a test framework buys you nothing.

An existing suite that works. A stable Puppeteer suite is not a problem in need of a migration. Rewriting working tests is a cost with no user-visible benefit, and the flakiness argument only applies if you actually have flakiness.

Tight coupling to the DevTools protocol. If you are doing something unusual with low-level Chrome APIs, Puppeteer's closeness to the protocol can be an advantage.

Why agent tooling standardized on Playwright

This is the part that changed the calculus in the last two years and is not really about either library's merits.

When coding agents started needing browsers, the tooling that grew up around that need targeted Playwright: browser MCP servers, agent test-generation tools, the surrounding ecosystem. Cross-engine support and a built-in runner made it the more complete target, and the ecosystem compounded from there.

The practical effect is that if you want an agent to open your application, verify a change it just made, and leave behind a test, the mature path runs through Playwright. See Playwright MCP for how that works, including why structured accessibility snapshots beat handing screenshots to a vision model.

The part neither library solves

Both give you a browser you can script. Neither has an opinion on the thing that actually breaks suites over time: tests bound to selectors that change.

A test that finds a button by CSS class works until someone renames the class. Multiply by a few hundred tests and a redesign, and you get a suite that fails for reasons unrelated to whether the product works. Teams then disable the noisy ones, and coverage quietly decays.

This gets worse with agent-written code, because agents refactor and rename more aggressively than cautious humans do. The rate of selector churn goes up exactly when test volume does.

Shiplight addresses that layer rather than replacing either library. Tests are written as intent, transpiled to Playwright plus an AI SDK, and run in ordinary Playwright browsers. When a cached locator goes stale, the step is re-resolved from intent against the current page instead of failing, and the heal appears as a reviewable diff. Because the output is Playwright, an existing Playwright suite keeps running alongside it, with no migration required.

Honest scope: web applications. Native mobile is not in it.

Which to pick

New E2E suite: Playwright. Auto-waiting, the runner and the trace viewer make it a lower-maintenance starting point, and the agent ecosystem is there.

Chromium scripting that is not tests: Puppeteer. Smaller and sufficient.

Existing Puppeteer suite that works: keep it. Migrate when you have a reason, such as needing WebKit coverage or fighting persistent flakiness.

Agents in your workflow: Playwright, because that is where the tooling is.

Frequently Asked Questions

Related Reading

• Playwright MCP: giving an agent a real browser through Playwright
• Playwright vs Cypress: the other framework comparison
• How to fix flaky tests: the failure mode auto-waiting only partly solves
• Locators are a cache: why selector-bound tests decay