8 browser automation tools I tried in 2026, ranked by daily use
Browser automation had a quiet moment this year. Between MCP shipping stable, Claude Code exposing Chrome directly, and Vercel's serverless Chromium story finally working, the floor for "AI that drives a browser" dropped from "you need a team" to "you need 40 seconds."
I ran real work through eight tools in the last two months. Landing page critiques, QA sessions, scraper prototypes, regression checks. Here's the stack, ranked by what I actually opened this week.
1. Chrome DevTools MCP - my daily driver
I use this every single day. Install once inside Claude Code:
claude mcp add chrome-devtools -- npx -y @modelcontextprotocol/server-chrome-devtools
After that, any time I ship a feature, I paste three lines and Claude opens my dev server, clicks through, measures elements, reads the console, and returns a pass or fail. Full workflow is in the QA post.
What makes it the winner: zero API key, zero rate limit, zero cost. It attaches to the Chrome I already have open. Every evaluate_script call runs against a real browser with real network. When I needed to verify SVG text bounding boxes a few weeks ago, nothing else would have caught what getBBox() caught. Full-page screenshots looked fine.
The one limitation: it drives your local Chrome, not a fleet. Good for QA, inspection, measurement. Bad for "critique a thousand URLs overnight."
2. Playwright - for anything I actually ship
When the browser work has to run without me (production, scheduled jobs, public-facing endpoints), it's Playwright. No debate. The API is clean, the docs are current, and it handles mobile emulation, multiple contexts, and network interception the way you'd want in a real codebase.
The Landing Page Critic build runs on it. You paste a URL, a Playwright headless Chromium opens the page in two viewports, screenshots both, extracts the above-fold text, and hands it to Gemini for scoring. Entire pipeline: 20 to 30 seconds.
Key choice: playwright-core plus @sparticuz/chromium for serverless deploys. The full playwright package ships a ~300MB Chromium which does not fit in Vercel Functions. The sparticuz build is ~50MB compressed and works inside a standard Node runtime.
3. agent-browser CLI - when Claude Code isn't in the loop
Command-line browser automation that takes a natural-language task and runs it to completion. Ships inside Claude Code skills but also works as a standalone CLI for scripts and cron jobs.
Where it wins: overnight scrapers, morning refresh jobs, anything you want to run on a schedule without a Claude session open. It's essentially "agent with a browser" as one binary.
Where it doesn't: interactive debugging. You hand it a task and wait.
4. Claude in Chrome extension (beta)
Anthropic's own browser extension. It sits inside Chrome, sees the page you're looking at, and can act on it with a "do this" prompt. Beta, and it shows, but the idea is the right one. If you want Claude to act on the thing you're already looking at without copy-pasting screenshots, this is the shortest path.
Where it wins: personal research flows, form-filling on pages you trust, quick "summarize this PDF" without leaving the tab.
Where it doesn't: automation you want to reproduce. There's no script to run twice.
5. Cloudflare Browser Rendering - my serverless fallback
REST API. You POST a URL, get a screenshot or rendered HTML back. Costs roughly $0.005 per render. I wired it as the fallback for the Landing Page Critic: if @sparticuz/chromium fails or cold starts too long on Vercel, the capture path fails over to Cloudflare with two env vars.
Where it wins: reliability at scale. No cold starts, no per-function memory budget, no Chromium binary to maintain. Your /api/critique stays small.
Where it doesn't: cost. Free tier is generous but not infinite. I'd rather burn function time than pay per render if I can help it.
6. Browserbase - managed, for when you stop caring about infra
Hosted headless browsers with a session recording UI. If you're building an agentic product that drives dozens of browsers in parallel and you do not want to think about Chromium binaries, this is the right shape. Session replays are great for debugging what the agent actually did.
Where it wins: agentic products with paying customers. You pay for certainty, you get certainty.
Where it doesn't: experimentation. The per-session cost stacks up fast when you're iterating on prompts.
7. Puppeteer - the older sibling
Puppeteer still works. Google maintains it, it's Chrome-first, it's been production for a decade. I used it on three previous projects and never once was mad at it. But Playwright caught up and passed it on cross-browser support, test runner integration, and iOS emulation. If you're starting today, start with Playwright.
Where it still wins: Chrome-only, narrow-scope scripts where you want the smallest possible dependency footprint. The API is tighter.
8. Selenium - don't, unless you have to
I used it in 2018 and I used it again this year for one reason: a legacy system only exposed IE11 via RemoteWebDriver. Selenium got the job done. The experience was exactly as painful as I remembered.
Where it wins: you're integrating with existing Selenium grid infrastructure at work.
Where it doesn't: everywhere else.
The decision table
Which tool, for which job:
| Job | Pick | Why |
|---|---|---|
| QA a feature you just built | Chrome MCP | 30s round trip, runs in your open browser |
| Measure an element, check a regression | Chrome MCP | evaluate_script with getBBox() beats screenshots |
| Ship a public browser-automation endpoint | Playwright + sparticuz | Fits Vercel Functions, well-supported |
| Overnight scraper or scheduled job | agent-browser CLI | No Claude session to keep open |
| "Act on this page I'm reading" | Claude in Chrome | Shortest distance from page to action |
| Production capture at scale with no infra | Cloudflare Browser Rendering | Fixed cost, zero cold start |
| Agentic product with paying users | Browserbase | Session replay, hosted sessions, SLA |
| You can only use Selenium | Selenium | I'm sorry |
What's about to change this stack
Computer use MCPs will eat the bottom half of this table within twelve months. Not because they're better at browsers (they're worse, right now) but because "drive a browser" is a subset of "drive a desktop." The day Anthropic or OpenAI ship a reliable general computer-use MCP, you'll ask it to use Chrome and it'll figure out the rest.
Today that's an interesting tech demo. By year end I think it's the default for any agentic workflow that's not latency-sensitive. Subject of the next post.
If you want to see the top of this stack running, Landing Page Critic uses Playwright plus Gemini 2.5 Flash. Paste your URL, get an AI-scored critique back. The Chrome MCP QA workflow shows how I use the #1 pick every day.
Want to see more projects like this? Browse all builds for interactive tools, dashboards, and case studies with source and build times. Or learn more about ShipWithTez.