browser-harness, Playwright, and Puppeteer: which browser automation tool should you choose?

In browser automation and automated testing, Playwright and Puppeteer are two of the most commonly compared tools. Both can control browsers, click pages, extract content, generate screenshots or PDFs, and both are closely related to Chrome DevTools Protocol.

Once browser-use/browser-harness is added to the picture, the question is no longer simply “which testing framework is stronger.” It becomes a comparison between two kinds of tools:

• Playwright / Puppeteer: tools for engineers to write deterministic scripts.
• browser-harness: a tool for AI agents to operate real browsers.

The first group fits testing, scraping, and engineered automation. The second is closer to a browser control layer for agents such as Claude Code, Codex CLI, and Gemini.

The relationship between Playwright and Puppeteer

Puppeteer was originally launched by the Google Chrome team and naturally focuses on Chromium and Chrome automation. Its API is concise, the ecosystem is mature, and it is especially convenient for screenshots, PDF generation, page scraping, and lightweight automation around Chrome.

Playwright is maintained by Microsoft, and its team has deep historical links to early Puppeteer work. It absorbed many lessons from Puppeteer and added stronger cross-browser support, auto-waiting, context isolation, test reports, and debugging tools.

In short:

• If you only need lightweight Chrome-based tasks, Puppeteer is still very pleasant to use.
• If you are doing cross-browser E2E tests, complex SPA automation, or team-level test engineering, Playwright is usually the better fit.

Core differences

Browser support

Puppeteer is strongest with Chrome. It integrates tightly with Chromium. If your goal is to control Chrome, generate PDFs, take screenshots, or run simple scraping tasks, Puppeteer has a low mental overhead.

Playwright is stronger for cross-browser work. It natively supports Chromium, Firefox, and WebKit. WebKit is especially important because many Safari-related issues cannot be detected through Chrome alone. For applications that need coverage across desktop, mobile, and multiple browser engines, Playwright is the better main tool.

This is the first decision boundary: if you only care about Chrome, Puppeteer is fine. If you are serious about cross-browser testing, choose Playwright first.

Auto-waiting and stability

The most annoying part of browser automation is often not “how to click,” but whether the page is ready. An element may not be attached to the DOM, may be covered, may still be animating, or may still be disabled.

In Puppeteer, you often write:

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

This works, but engineers must think through the waiting logic themselves. The more complex the page, the more likely the script will accumulate waitForSelector, waitForTimeout, and retry logic.

Playwright’s Locator and auto-waiting mechanism is more complete:

1

await page.locator('#submit-btn').click();

Before clicking, Playwright checks whether the element is visible, actionable, stable, and not covered, then retries within a reasonable time. This matters a lot for modern React, Vue, and Next.js applications with heavy asynchronous rendering, and it reduces flaky tests.

Multi-account workflows and context isolation

If you need to simulate multiple users, or let many tasks share one browser process while isolating Cookie, LocalStorage, and Session, BrowserContext matters.

Puppeteer also supports context isolation, but Playwright makes it a core capability. You can quickly create multiple independent contexts inside one browser instance. Each context behaves like a clean browser environment without repeatedly starting full browser processes.

This is useful for:

• Multi-account concurrent tests.
• Multi-role workflow tests.
• Ecommerce, messaging, and collaborative document scenarios.
• Scraping tasks that need isolated Cookie and login state.

Tooling differences

Playwright is the more engineering-oriented option. It includes many tools used in test development:

• codegen: operate on a webpage and generate scripts automatically.
• Trace Viewer: replay screenshots, DOM snapshots, network requests, and console logs after failures.
• Test Runner: assertions, parallelism, retries, reports, and project matrices.
• Locator: element selection by text, role, label, test id, and CSS.

Puppeteer is more like a lightweight browser control library. It is not bloated, its API is direct, and it is easy to embed in scripts, server-side jobs, and custom automation flows.

If you are building an enterprise-grade test system, Playwright’s tooling saves a lot of work. If you only need a Node.js script to convert webpages to PDFs or take scheduled screenshots, Puppeteer may be cleaner.

Where browser-harness fits

browser-harness is not the same kind of tool as Playwright or Puppeteer.

Playwright and Puppeteer mostly assume that humans write scripts. Engineers choose selectors, waiting conditions, assertions, and exception handling. They pursue determinism: the same script should produce the same result under the same page state.

browser-harness mostly assumes that an AI agent operates the browser. Its goal is not to provide a huge high-level API, but to connect to real Chrome through CDP and expose screenshots, coordinate clicks, DOM, network requests, and helpers to the agent. The agent can observe the page, decide the next step, add helpers when capabilities are missing, and turn site experience into skills.

That makes it better for open-ended tasks:

• Log in to a backend and download invoices.
• Fill a group of forms in an internal system.
• Handle OA or SaaS pages that change often.
• Explore a page according to a user goal instead of running a fixed script.
• Give tools such as Claude Code and Codex CLI browser operation capability.

Three-way comparison

Code feel

Puppeteer feels closer to directly controlling Chrome:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright emphasizes Locator and auto-waiting:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness feels completely different. You usually do not write a full script. You give a goal inside an agent environment:

1

Open the admin panel, download last month’s invoice, and organize it for reimbursement.

The agent then repeatedly uses browser-harness to:

• Take screenshots and understand the current page.
• Click a coordinate or locate an element.
• Enter text, upload files, and download files.
• Decide how to close popups.
• Add helper code when something is missing.
• Turn reusable flows into domain skills.

This is not the style of traditional test scripts. It is the workflow of a browser agent.

How to choose

Choose Puppeteer when:

• The project mainly runs in Node.js.
• You only need Chrome or Chromium.
• The task is screenshot, PDF generation, simple page scraping, or lightweight automation.
• You want a simple API, fewer dependencies, and more manual control.
• You rely deeply on Chrome DevTools Protocol.

Choose Playwright when:

• You are building standard UI automation or E2E tests.
• You need Chromium, Firefox, and WebKit coverage.
• Your team’s main language may be Python, Java, or C#.
• The page is a complex SPA with many asynchronous states and potential flaky tests.
• You need codegen, Trace Viewer, test reports, and parallel testing.

Choose browser-harness when:

• You are building or using AI agents.
• You want the model to operate a real browser like a human.
• The task steps are not fixed and require page-by-page judgment.
• The target site changes often, or has many popups, iframes, and shadow DOM.
• You want real web workflows handled by Claude Code, Codex CLI, or similar tools.

Conclusion

Playwright and Puppeteer are browser automation tools whose core goal is to let humans write reliable scripts. Puppeteer is lighter and closer to Chrome. Playwright is more complete and better for cross-browser testing and complex frontend applications.

browser-harness is a different direction. It is not designed to replace Playwright or Puppeteer for tests. It is designed to let AI agents control real browsers. It gives up some traditional script determinism in exchange for stronger adaptability in open-ended tasks.

So the answer is not to pick only one. Choose by task layer:

• Test engineering: prefer Playwright.
• Lightweight Chrome scripts: Puppeteer fits well.
• AI agents doing work on the web: look at browser-harness.

References:

• browser-use/browser-harness: https://github.com/browser-use/browser-harness
• Playwright documentation: https://playwright.dev/
• Puppeteer documentation: https://pptr.dev/
• Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/