Home / Blog / What is Playwright?

What is Playwright?

Updated 31 August 2026 · Playwright 1.62

Someone asking this is usually deciding one thing: whether Playwright covers what they need to test. That turns less on the feature list than on what the thing being tested is — a web application that runs in a browser, or an application people install from a store.

What is Playwright, exactly?

The documentation defines it in one sentence: "Playwright Test is an end-to-end test framework for modern web apps. It bundles test runner, assertions, isolation, parallelization and rich tooling." Microsoft publishes it on GitHub under the Apache License 2.0.

The package is two things, and readers trip over the split sooner or later. Playwright Library drives browsers; Playwright Test is the runner built on top of it, and npm init playwright@latest installs it. The library documentation states the division: "Playwright Library provides unified APIs for launching and interacting with browsers, while Playwright Test provides all this plus a fully managed end-to-end Test Runner and experience."

The same page lists what the Library goes without: web-first assertions that retry, the configuration matrix that runs one test across several browsers, parallelisation, reporting, retries and tracing. Cleanup is manual there too — you close the context and the browser yourself. For end-to-end testing you want the runner.

Either way it drives three engines from one API: Chromium, Firefox and WebKit. That API ships in four official bindings — TypeScript and JavaScript through the Node.js package, then Python, Java and .NET. Firm86 delivers suites in all four.

Playwright downloads its own builds of those three browsers and drives them directly, rather than attaching to a copy of Chrome you installed. The consequences of that are worked through in how Playwright is built.

What is Playwright used for?

End-to-end tests of a web application are the main job. One suite runs against all three engines, with the browser matrix as a few lines of configuration.

Mobile web. A device descriptor emulates a phone by setting the user agent, the screen size, the viewport and the touch flag, with locale, timezone and geolocation on the same switch. Responsive layouts and touch behaviour are testable that way.

API calls alongside browser tests. The API testing guide frames this as testing your server API, preparing server-side state before the browser opens the page, and checking it afterwards. It is a request client in the same test file as the browser test, and it is not pitched as a replacement for a dedicated API tool.

Component tests. Playwright can mount a single component in a real browser and drive it the way it drives a page; in 1.62 that runs through stories and a gallery page.

Accessibility feedback. Role locators are built on ARIA roles and accessible names, so a test written with them fails when the accessible name disappears. The locators documentation is careful about the claim: role locators do not replace accessibility audits and conformance tests, they give early feedback against the ARIA guidelines.

Playwright now also ships tooling aimed at coding agents, including an MCP server and a command-line interface built for them, which is the subject of Playwright and AI test generation.

What is Playwright not for?

The framework has edges, and they are cheaper to learn now than in month three.

Where each of these limits costs a team something, and where it costs nothing, is argued at length in the case for and against Playwright.

What does Playwright replace, and what does it not?

Adopting Playwright deletes some things from a toolchain and leaves others where they are.

Playwright does not ship a Grid replacement, which is where that row gets misread. It installs its browsers next to the tests and takes concurrency from workers in the config file and from sharding the run across CI jobs, so the Grid's job becomes configuration and CI capacity. If your next question is the direct comparison, it is in what actually breaks when a Selenium suite moves.

What does it cost a team to run Playwright?

The licence costs nothing. The running has a bill, in two places.

The first is disk. Every machine that runs tests keeps its own copies of the browsers, in %USERPROFILE%\AppData\Local\ms-playwright on Windows, ~/Library/Caches/ms-playwright on macOS and ~/.cache/ms-playwright on Linux. The browsers documentation prints its own du -hs output for those folders: 281M for Chromium, 187M for Firefox, 180M for WebKit. The three add to 648M, so call it about 650MB per machine. Those figures move with every release; they are not a fixed specification.

The second is CI. The official image is mcr.microsoft.com/playwright:v1.62.0-noble, which pins the browsers and their operating-system dependencies to the Playwright version. The CI documentation's advice on caching those binaries: "Caching browser binaries is not recommended, since the amount of time it takes to restore the cache is comparable to the time it takes to download the binaries." The same page adds that the operating-system dependencies cannot be cached at all.

The other CI figure to know is the worker count. Playwright defaults it to the detected core count, and the CircleCI section of that page warns that raising it above what the machine has "will cause unnecessary timeouts and failures" — on a CircleCI medium executor the detected count is 2. A CI agent is smaller than the laptop the suite was written on.

We have not measured a total, so this page does not publish one. It depends on how many machines run the suite and what your CI provider charges for the minutes.

Which teams should not adopt Playwright?

A team whose product is an app people install from a store, and whose only web presence is a marketing site, would be buying a browser tool to test a marketing site. That can still be worth doing, and it is a smaller decision than the one they thought they were making.

If your one supported browser is Safari on real iOS hardware and the contract names the hardware, you need a device cloud before you need a framework.

Anyone who came looking for a load-testing tool is looking at the wrong kind of tool, and no Playwright release is going to change that.

A team with no continuous integration will not keep the suite. Tests that run on somebody's laptop when they remember rot at the same speed in every framework, and the first fix there is the pipeline.

On the other side of that list is a web application, a browser matrix you can name, a pipeline that already runs on every commit, and nobody with the time to write the specs. For that team the engagement is building an end-to-end Playwright suite.

A first Playwright test

One test, whole, as it would sit in a repository:

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

test('adding a kettle puts it in the basket', async ({ page }) => {
  await page.goto('https://example.com/products/kettle');
  await page.getByRole('button', { name: 'Add to basket' }).click();

  await expect(page.getByTestId('basket-count')).toHaveText('1');
});

Playwright 1.62 · TypeScript

There is no browser to launch and no driver to start in that test, because the page fixture arrives ready. There is no explicit wait before the assertion, because toHaveText re-fetches the element and re-checks it until it passes or the assertion timeout is reached, five seconds by default. And there is no teardown, because the runner closes what it opened.

The locator reads the way a person describes the page: the button labelled "Add to basket". For the same test with fixtures, configuration and a project layout under it, start at the Playwright tutorial.

Questions