Developer tools#Browser automation

Playwright: one API to drive Chromium, Firefox and WebKit

Playwright drives Chromium, Firefox and WebKit with one API: auto-waiting, resilient locators, Trace Viewer and parallel runs for tests and scripts alike.

Project facts

GitHub Ecosystem
Repositorygithub.com/microsoft/playwright
License
Apache-2.0
Language
TypeScript
Stars
97,768
Data checked
2026-10-15

Snapshot figures reflect the check date and may change over time.

Taking a “scrape this, monitor that, fill in this form” contract, the first question is not whether the tool runs — it is whether switching browsers means a rewrite. Playwright is the Microsoft-maintained standard answer (TypeScript, Apache-2.0, about 97.8k stars as of 2026-10-15): one API drives Chromium, Firefox and WebKit, and tests, scripts and agent tooling all build on it.

Core features

  • One API, three engines: Chromium (156), Firefox (157) and WebKit (27.2) share one interface — the README badges pin the versions; write once, run across browsers.
  • Auto-waiting and web-first assertions: no hardcoded sleeps. Elements are acted on when actionable, and assertions retry until conditions hold, which removes the largest source of flaky tests.
  • Resilient locators: getByRole, getByLabel, getByPlaceholder and getByTestId find elements the way users see them, so small DOM restructures do not necessarily break the test.
  • Isolation with state reuse: each test runs in its own browser context (a fresh profile); login state is saved once with storageState and reused, so no test re-authenticates from scratch.
  • Trace Viewer: on failure it captures traces, screenshots and videos, then replays every action, DOM snapshot, network request and console message.
  • Parallel by default: tests run in parallel across all configured browsers.
  • Four entry points, one core: Playwright Test (end-to-end testing), the CLI (for coding agents — the README says it is more token-efficient than MCP because commands avoid loading large tool schemas and accessibility trees into context), MCP (LLM-driven automation) and the Library (plain automation scripts).

Typical use cases

  • A developer delivering scraping or monitoring work: competitor prices and bulk public-record pulls run from one script across all three engines.
  • A front-end team adding E2E coverage: auto-waiting plus Trace Viewer turns “mysteriously flaky” into replayable evidence.
  • A team giving coding agents web access: both the CLI and MCP ship in the official repos — pick by your token budget.

Quick start

npm init playwright@latest

Or add the dependency and install browsers manually:

npm i -D @playwright/test
npx playwright install

A first test:

import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
});

Run it with npx playwright test — headless and parallel by default. To inspect a failure, add trace: 'on-first-retry' to the config and open it with npx playwright show-trace trace.zip.

Summary

For teams writing E2E tests, developers delivering browser automation, and teams wiring web access into agents. It is not the tool for driving a real user profile — installed extensions and specific fingerprints — because Playwright gives you a clean, isolated context rather than your everyday browser. TypeScript, Apache-2.0, 97,768 stars as of 2026-10-15 with pushes the same day; maintained by Microsoft with a mature ecosystem.

Of the two agent paths, our earlier entry on Playwright MCP covers the MCP server form (LLM-driven, operating through the accessibility tree); the Playwright CLI is the same team’s lighter alternative for coding agents — which one fits depends on how your agent consumes tools.