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- 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,getByPlaceholderandgetByTestIdfind 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
storageStateand 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.