Updated May 14, 2026.
Browser automation is a control-surface choice: deterministic script, browser agent, MCP browser bridge, or no browser at all. Pick the smallest surface that can finish the job and leave a receipt.
Quick decision
| Task shape | Pick | Why | Evidence to save | Avoid if |
|---|---|---|---|---|
| Stable, repeatable UI flow | Playwright script | Selectors, assertions, traces, and cross-browser checks are the job | URL, screenshot, trace or exit code, parsed output | The page changes every run |
| Chrome/CDP or browser-protocol-heavy work | Puppeteer | Puppeteer exposes a high-level API for Chrome or Firefox over DevTools Protocol / WebDriver BiDi | screenshot, extracted values, protocol/network note | You need broad cross-browser test coverage |
| Exploratory or changing UI | browser-use | The path is not fully known ahead of time and an LLM-driven browser loop is acceptable | prompt, action log, screenshots, extracted values | The action is destructive, expensive, or unverified |
| Browser control inside a coding/debug loop | Playwright MCP | The browser needs to sit next to code edits, tests, and agent context | transcript, accessibility snapshot or screenshot, local URL, final state | A plain script or CLI check is enough |
| API, export, or raw HTTP already exists | No browser automation | UI adds failure without adding value | API response, export file, diff | The UI is the product surface you must verify |
| Payment, permission, delete, publish, or account admin action | Human gate | The blast radius is higher than the automation gain | human approval record and rollback note | You would let the robot click the final button |
Rule of thumb: agent for discovery, script for repeatability. If a browser agent finds the path through a messy UI, turn the winning path into Playwright when the task becomes routine.
For adjacent decisions, see browser agents vs Playwright , Playwright MCP , best MCP servers by job , and sandboxing security .
The receipt template
Browser automation without evidence is just a confident hallucination with a mouse. Save one receipt per run.
| Field | What it records |
|---|---|
| task | What the browser had to do |
| target | App, URL, and environment |
| tool | Script, agent, MCP server, or hosted browser |
| start state | Logged in or not, account type, seed data |
| selector / prompt plan | Selectors, navigation path, prompt, or agent goal |
| evidence | Screenshot, URL, page title, extracted values, trace, or transcript |
| outcome | pass / fail / partial |
| human sign-off | Whether a destructive step needed approval |
| rollback / fallback | What happens if the run is invalid |
If there is no receipt, there is no claim.
Playwright: stable flows and test discipline
Use Playwright when the UI is known and repeatability matters. The docs position it as browser automation for Chromium, WebKit, and Firefox across Windows, Linux, and macOS, with headed or headless runs, assertions, isolation, parallelization, and tooling around tests.
The useful parts for agents are boring in the best way:
- codegen can generate tests as you click through a flow, prioritizing role, text, and test-id locators;
- Trace Viewer lets you inspect what happened after a run;
- selectors and assertions make the final flow reviewable instead of vibes-based.
Playwright is usually the right endpoint after discovery. Let an agent explore. Keep the repeated job as a script.
Puppeteer: browser-protocol work from Node
Use Puppeteer when the work is browser-protocol-heavy and the team is already in JavaScript. Current Puppeteer docs describe it as a high-level API for controlling Chrome or Firefox over the DevTools Protocol or WebDriver BiDi, running headless by default.
That makes it a strong fit for Node-first automation where the browser itself is the integration surface. Do not describe it as limited to Chrome; that is stale. Also do not choose it just because it feels lighter. Choose it when the protocol/API shape is the reason you are automating.
browser-use: exploratory browser agents
Use browser-use when the task is exploratory enough that hardcoding selectors first would be fake precision. Its README frames it as an open-source Python browser-agent library with LLM quickstart flows, custom tools, deep integration options, and both self-hosted/open-source and hosted cloud paths.
That does not make it magic. Avoid universal-autonomy claims unless the current docs say the exact thing and you are willing to source it. Treat it as an agent loop that still needs a receipt, a safe account boundary, and a human gate for destructive actions.
Good fit:
- one-off admin research;
- changing dashboards;
- exploratory QA;
- migration flows where discovering the path is the hard part.
Bad fit:
- stable nightly scraping;
- deterministic E2E tests;
- payment, deletion, invitation, publish, or permission changes without approval;
- anything where you cannot define the receipt before running.
Playwright MCP: browser control inside the agent loop
Use Playwright MCP when an MCP-capable coding agent needs browser access while it edits, runs, debugs, or verifies software. The project README describes an MCP server for browser automation that uses structured accessibility snapshots rather than screenshot-based page reading, and is meant to be LLM-friendly and deterministic.
The important distinction: Playwright MCP is a bridge, not a safety boundary. It gives an agent browser control. It does not make logged-in sessions, secrets, local apps, or production dashboards safe by itself.
Use it for:
- checking localhost after code edits;
- reproducing a UI bug;
- collecting screenshots or page state for a coding agent;
- browser steps that belong inside a broader development loop.
Do not use it as a substitute for account policy, sandboxing, or human approval. If credentials or blast radius are the real problem, read sandboxing security first.
Failure modes
| Failure mode | Symptom | Response |
|---|---|---|
| Login wall or expired session | The run stops at auth | Use a test account or stop |
| Captcha / bot check | The page blocks automation | Treat it as infra/risk, not selector drift |
| Slow JavaScript / race condition | Click happens before state is ready | Wait on state and capture a receipt |
| Hidden modal, iframe, or shadow DOM | The visible page does not match the DOM | Inspect the render tree before retrying |
| Selector drift | The script works once and then breaks | Prefer stable semantic selectors or a browser-agent discovery pass |
| Destructive button | The step can change money, data, or access | Require human approval before the final action |
| Extraction mismatch | Output does not match the page | Compare against the receipt and re-run read-only |
Use neither
Use neither browser automation nor browser agents if the task can be done by API, export, raw HTTP, or a one-off human click with no repeatability. The browser is a terrible API wearing nice pants.
If the job is privacy-sensitive, credential-heavy, or connected to real money/access, the first decision is not Playwright vs Puppeteer. It is whether you have a safe account, a rollback path, and a human approval gate.
Related
- Browser agents vs Playwright — when to use judgement instead of selectors
- Playwright MCP — MCP browser control for coding agents
- Best MCP servers by job — permission and validation matrix
- Browser agents — concept layer for browser-using agents
- Agent failure modes — why agent/browser loops break
- Sandboxing security — account and blast-radius boundaries