Playwright MCP vs Puppeteer MCP: Browser Automation 2026

If you want Claude to control a real browser (click through a flow, fill a form, scrape a page that only renders with JavaScript, test a web app), you install a browser-automation skill. Two dominate the choice: one built on Playwright, one built on Puppeteer. They look similar from the outside. The differences show up the moment you try to do real work, and picking wrong means fighting your tools instead of using them.

I've run both against the same set of tasks: login flows, dynamic pages, a flaky checkout. Here's how they actually differ and which one to install.

The quick comparison

The real difference: how each one "sees" the page

This is the distinction that matters and the one most comparisons skip.

The Playwright MCP server hands Claude a structured accessibility tree, a text representation of what's on the page, with roles and labels. Claude reads that tree, finds the "Sign in" button by its accessible name, and clicks it. No image required. That's faster, cheaper in tokens, and more reliable, because Claude is acting on structure instead of guessing pixel coordinates from a screenshot.

Most Puppeteer-based MCP servers lean on screenshots and raw DOM. Claude takes a picture, reasons about it, and acts. That works, but it burns more tokens on every step (images are expensive), and it's more fragile, since a layout shift or a slow render throws it off in ways the accessibility-tree approach shrugs at.

For an agent driving a browser, the structured approach wins most of the time. It's the single biggest reason to default to Playwright.

Where Playwright MCP pulls ahead

Reliability. Playwright auto-waits for elements to be ready before acting. Puppeteer often needs you (or the agent) to handle timing manually, and timing bugs are the number-one cause of flaky automation. Less babysitting.

Cross-browser. Playwright drives Chromium, Firefox, and WebKit (Safari's engine) from the same setup. If you need to confirm something works in Safari, this is the only one of the two that can. Puppeteer is Chrome-and-Chromium in practice.

Token cost. Because it works off the accessibility tree instead of screenshots, a Playwright-driven session spends meaningfully fewer tokens on the same task. Over a long automation run, that's a real bill difference.

Official support. Microsoft maintains the Playwright MCP server directly. Puppeteer MCP servers are community projects, some good and some abandoned, so you're trusting a specific fork's maintainer.

Where Puppeteer MCP still makes sense

It's not a clean sweep. Puppeteer has a longer history and a huge body of examples and Stack Overflow answers, so if your team already knows Puppeteer cold, the familiarity has value. For dead-simple Chrome-only scraping where you don't care about cross-browser or token cost, a Puppeteer MCP server gets the job done and you may already have the mental model for it. The case is "we already use this and it's fine," not "it's technically better."

Installing them

Playwright MCP (the one I'd default to):

claude mcp add playwright -- npx -y @playwright/mcp@latest

Then install the browser binaries it needs:

npx playwright install chromium

Puppeteer MCP:

claude mcp add puppeteer -- npx -y @modelcontextprotocol/server-puppeteer

Restart Claude Code after either, and confirm the tools show up before you build anything on top.

Security: this is the part people skip

A browser-automation skill is one of the higher-risk things you can hand an agent, because it acts in a real browser with whatever that browser can reach. Take this seriously.

• Don't run it logged into accounts you can't afford to have touched. Use a separate browser profile or a throwaway session, not the one holding your bank and email.
• Scope what it can navigate to. An agent that can open any URL can be steered somewhere you didn't intend if it's acting on instructions pulled from a page. Treat page content as untrusted input.
• Watch for actions that spend money or send messages. A checkout flow or a "send" button executed by an agent is a real transaction. Keep a human approving anything irreversible.
• Prefer the official, source-available server. Playwright's is maintained by Microsoft with public code you can read. For Puppeteer, check which fork you're installing and whether it's actively maintained before trusting it.

The risk isn't hypothetical. An automation that can click and type can do damage at machine speed. Sandbox it.

What a first task actually looks like

If you've never driven a browser with an agent, the gap between the two tools is easiest to feel on a concrete job. Say you want Claude to log into a dashboard, read a number off a chart, and drop it in a file every morning.

With Playwright MCP, you describe the steps in plain language and the agent works off the accessibility tree: it finds the username field by its label, types, finds the password field, finds the "Log in" button by name, waits for the dashboard to load on its own, then reads the value. The auto-waiting means you don't write timing logic, and the whole run stays cheap because nothing took a screenshot.

With a Puppeteer server, the same job tends to involve more screenshots and more explicit "wait for this to appear" handling. It works, but you feel the difference on a flaky morning when the dashboard loads half a second slow: Playwright waits, the screenshot approach guesses.

Multiply that small reliability edge across a task that runs daily for a year and the choice makes itself. The first build takes ten minutes either way. It's the hundredth unattended run where Playwright's structure-first approach quietly saves you from a 6 a.m. "automation broke" message. Build your first task on whichever you install, watch it run a few times unattended, and you'll know within a week whether it earns your trust.

The verdict

For almost everyone, install Playwright MCP. It's more reliable, cheaper in tokens, works across browsers, and it's officially maintained. The accessibility-tree approach is just a better fit for how an agent should drive a browser, and the auto-waiting alone removes a class of bugs you'd otherwise chase for hours.

Reach for Puppeteer MCP only if your team already lives in Puppeteer or you have a narrow Chrome-only scraping job and don't want to learn anything new. It's a fine tool; it's just the second pick now.

If you're assembling a broader automation stack, see our roundups of browser-automation skills and web-scraping skills, and the step-by-step Playwright MCP install guide if you want the long version of the setup.

FAQ

Which is faster for an AI agent? Playwright, in most cases, because it acts on a text accessibility tree instead of screenshots. Fewer images means fewer tokens and quicker reasoning per step. Puppeteer's screenshot-heavy approach is slower and pricier over a long run.

Can I use Puppeteer skills to test in Safari? No. Puppeteer is Chromium-focused. If you need WebKit (Safari's engine) or Firefox, Playwright is the only one of the two that drives them.

Do I need to know how to code to use these? You need to run a couple of terminal commands to install, but driving the browser happens in plain language once it's set up. You describe the task; the agent executes it through the skill.

Is it safe to let Claude control my real browser? Only with precautions. Use a separate profile, don't stay logged into sensitive accounts, keep a human approving anything irreversible, and treat web-page content as untrusted. Run it sandboxed, not on the browser holding your real life.

Can the two run side by side? Yes. There's nothing stopping you from installing both and pointing the agent at whichever fits a given job. In practice most people don't bother once Playwright is set up, but if you have an existing Puppeteer workflow you want to keep while you migrate, running them together is fine.

What about Selenium MCP? Selenium is the old guard and there are MCP servers for it, but for an agent-driven workflow in 2026 it's behind both options here: slower, more boilerplate, and no real upside over Playwright. Start with Playwright unless you have a specific Selenium dependency.

The honest summary: Playwright MCP is the better tool for almost every browser-automation job an agent will do, and the gap is widest exactly where it counts — reliability and cost. Pick Puppeteer only when you have a reason that isn't "it's what I know."