Playwright

Browser automation is easy in a demo. Production is different. Sessions expire. Buttons move. A page loads in two seconds today and eight seconds tomorrow. If the tool works only once on a clean page, I do not need it.

I need the same workflow to run again in CI and fail clearly when the result is wrong. Playwright does that. I use it on this site as a release check against the final static build, not the dev server.

Verdict: RUNNING. Browser control agents can rely on.

What is Playwright and what does it do?

Playwright is Microsoft's open-source framework for browser automation and end-to-end testing. It drives a real browser the way a person would: opens a page, fills a form, clicks, uploads a file, reads what came back. The difference from a script that clicks coordinates is that it waits for the page to be ready first, and it records what happened so a failure comes with evidence.

What people use it for, in rough order of how often I see it: end-to-end tests that gate a release, automating a workflow behind a login, scraping pages that need JavaScript to render, taking screenshots or PDFs at scale, and giving an AI agent a browser it can operate.

One API runs Chromium, Firefox, and WebKit. Headed locally. Headless in CI. It runs on macOS, Windows, and Linux. JavaScript and TypeScript are the main route, with official support for Python, .NET, and Java.

There are four useful ways to run it:

• Playwright Test for repeatable end-to-end tests, assertions, retries, reports, and traces.
• Playwright Library for scripts, screenshots, PDFs, scraping, and custom browser jobs.
• Playwright CLI when a coding agent needs short browser commands inside a repository.
• Playwright MCP when an MCP client needs browser tools during an agent workflow.

The project is free under Apache 2.0. Start with the official documentation: https://playwright.dev/docs/intro.

Why Playwright stays RUNNING in my stack

The main reason is waiting. Playwright does not click as soon as it finds a selector. It checks whether the element is visible, stable, enabled, and able to receive the action. If those checks fail, the click fails. Good. I want the failure.

An agent can say that it clicked a button. That means nothing by itself. I want an assertion after the click and a trace when the assertion fails. The exact actionability checks are documented here: https://playwright.dev/docs/actionability.

The tests for GetAgentTools run against the built files. They check navigation, forms, mobile overflow, metadata, structured data, and the review pages. A green build alone is not enough. The browser has to open the page and complete the path.

When a test fails, the trace shows the actions, DOM snapshots, screenshots, console messages, and network requests. I can see what happened. The next agent can see it too. Less guessing.

What makes Playwright useful for AI agents

Locators can use roles, labels, and visible text. That is better than clicking fixed screen coordinates. Browser contexts keep jobs isolated. Saved authentication state handles approved login flows. Traces leave evidence.

This does not make every website stable. A third-party UI will change. Sessions will expire. Networks will fail. CAPTCHAs and rate limits will stop the job. Playwright does not fix those problems. It makes them easier to see and handle.

How an agent actually gets Playwright as a tool

Four routes to the same browser, and the choice matters less than people think. What matters is who holds the session and who sees the failure.

• Playwright Test. The agent writes and runs tests in the repo. This is how I use it most: the checks live in version control, run in CI, and fail the build when a path breaks.
• Playwright Library. A short script for a one-off job. I used it to render the diagrams on this site at two viewport widths and look at them before publishing, which is a thing no assertion catches.
• Playwright CLI. Short browser commands for a coding agent working inside a repository, without wiring up a protocol.
• Playwright MCP. The official server, for when an agent needs browser tools during a longer exploratory workflow rather than a scripted one. That is the same tradeoff as any other MCP server: convenience against a wider surface the agent can reach.

There is a fifth route people search for: PlaywrightBrowserToolkit, LangChain's wrapper that hands the browser to a LangChain agent as a set of tools. It works, and I do not use it. My reason is boring rather than technical: it ties browser access to one framework, while the CLI and the MCP server do not. If your stack is already LangChain, the toolkit is the shortest path and the argument flips.

Who Playwright is best for

Web automation behind a login. I reach for Playwright when the workflow needs JavaScript, cookies, redirects, uploads, dialogs, or a page behind a login. I also use it when an HTTP 200 is not enough and I need proof that the user path works.

When to skip Playwright and use plain HTTP

Plain HTTP gets the data. If a normal HTTP request returns the data, use the request. A browser takes more memory, more time, and more work to maintain.

I also do not let an agent use it for an irreversible production action without approval. Playwright can click Delete or Publish. That does not mean it should.

Playwright vs Selenium, Puppeteer and Cypress

All four drive browsers. The honest summary is that the gap between them is smaller than the marketing suggests, and the thing that decided it for me was not speed.

• Selenium is the oldest and the most portable: W3C WebDriver, the widest language and browser support, and a grid ecosystem for scale. The tradeoff is that waiting is your job. Explicit waits scattered through a suite is exactly the pattern that produces flaky tests nobody trusts.
• Puppeteeris Google's library, JavaScript first, and grew up Chromium first. If your target is Chrome and your job is scripted rather than asserted, it is a clean fit.
• Cypress has the best developer experience of the four when you are writing tests by hand and watching them run. Its architecture runs the test alongside the page, which is what makes it pleasant and also what historically made cross-origin flows and multiple tabs awkward.
• Playwright gives one API across Chromium, Firefox, and WebKit, waits for elements as a built-in rather than a habit you have to remember, isolates sessions per context, and records a trace you can open after a failure.

For an agent, the last two points are the whole argument. Built-in waiting means the failure happens at the right moment instead of three steps later, when the cause is already off screen. The trace means I can check what the agent did rather than take its word for it. Everything else, language support, speed, ecosystem, matters more to a human test author than to a machine operating a browser unattended.

If you already run a working Selenium grid, none of this is a reason to migrate. Rewriting a passing suite to gain a nicer waiting model is a project with no user-visible result.

Playwright vs browser-use

browser-use is an open-source Python agent framework: you give it a task and a model, and the model reads the page and decides what to click or type next instead of a person scripting the steps. It started out built directly on top of Playwright.

It does not run on Playwright any more. In an August 2025 post, the browser-use team explained why they left it and moved to the Chrome DevTools Protocol instead: Playwright's own architecture added a second network hop through a Node.js relay process, which cost latency across thousands of protocol calls and let state drift across three different runtimes, the live browser, the Playwright relay, and the Python client. They also listed concrete limits they had hit on Playwright: full-page screenshots that reliably crashed past 16,000 pixels of page height, alert handling, file uploads on remote browsers, and crashed tab management. Proper cross-origin iframe support they list among the gains of the move.

That cuts against the point above, that speed matters more to a human test author than to a machine operating a browser unattended. The difference is volume. browser-use fires thousands of protocol calls to read the state of a page, checking element position, opacity, paint order and aria properties, so a relay hop that barely registers in a CI run starts to matter.

None of that makes Playwright the wrong pick for the job this review is about. Playwright stays the stronger choice for a scripted, repeatable test suite in a language a team already uses, with waits and traces built for a human or a CI pipeline to read. For an agent you already run, both projects now offer a browser route: Playwright through its CLI and MCP server, browser-use through a CLI of its own. What browser-use adds on top is the agent itself, a Python library that runs its own loop and lets a model pick every next click. In my stack, a flow that runs once and that nobody can script in advance already goes to an agent I run: Claude Code on my logged-in browser through claude --chrome. Pick the browser-use library when you want that loop off the shelf rather than a browser for an agent you already have.

Is Playwright free? What you pay for in practice

Yes, Playwright is free. Apache 2.0, no paid tier, no licence per run, no seat count. Microsoft develops it in the open and the browsers it downloads are free too. There is nothing to buy and nothing to renew.

Is it really open source? Yes. Go to microsoft/playwright on GitHub and open LICENSE: Apache License 2.0. Free of charge, royalty free, commercial use not excluded. On npm, playwright and @playwright/mcp say Apache-2.0 too. I looked at all three on 17 October 2026.

Where Microsoft does charge: Playwright Workspaces, inside Azure App Testing. It runs your Playwright tests on browsers in Microsoft's cloud and bills per test minute once the free trial ends. The trial lasts 30 days and covers the first 100 test minutes. You are paying for hosted browsers there, not for Playwright. I do not use it. The test suite for this site runs without it.

The bill, when there is one, comes from four places when you run it yourself:

• CI minutes. The dominant cost at any real scale, and the one that grows quietly as the suite does.
• Machines. Browsers want memory. Running many in parallel is the fastest way to need a bigger runner.
• Artefact storage. Traces and video are worth keeping on failure and wasteful on every pass. Configure that deliberately.
• Proxies, if the workflow needs them. That is a third-party subscription, not a Playwright cost.

Concretely, on this site: 56 end-to-end tests run against the final static build in about eight seconds on a laptop, on free tooling, with no hosted service in the loop. That is the shape of the cost at small scale. It is zero, and it stays near zero until a suite gets big enough to care about CI time.

So I start with HTTP. I add a browser only when the browser is needed. Simple.

How to get started with Playwright

Pick the version that matches the job.

1. For end-to-end tests, run npm init playwright@latest, then npx playwright test.
2. For a coding agent, install the CLI with npm install -g @playwright/cli@latest, then add its agent skills with playwright-cli install --skills.
3. For an MCP client, add the official server. In Claude Code the command is claude mcp add playwright npx @playwright/mcp@latest.

Start with one path. Open the page. Do one action. Check the result. Turn on tracing before the workflow gets bigger. The MCP guide is here: https://playwright.dev/mcp/introduction.

Playwright in production: rules that keep it stable

Playwright can save cookies and headers in an authentication state file. Treat that file as a password. Keep it out of git. Use a separate account with the minimum permissions. Rotate the state when the job no longer needs it.

The official authentication guide explains the setup: https://playwright.dev/docs/auth.

For agents I add a domain allowlist, approval before destructive writes, and a trace for failed or sensitive runs. No bypassing CAPTCHAs. No ignoring rate limits. No pretending that browser access is permission.

Where Playwright fits with agents and MCP

First HTTP. Then the Playwright Library when I need a real browser. Playwright Test when the flow has to become a release gate. CLI or MCP when an agent needs to control it.

Claude Code handles the repo work and decides what to check. Playwright runs the browser and returns evidence. Other agents can get the same browser through MCP servers. Clear job for each tool. That setup works.

One boundary worth stating: when a platform has a real API, use the API. I reach for a browser on ad platforms only for the parts the Meta Ads API does not expose. A supported endpoint outlives a selector, every time.

Playwright FAQ