The short answer, before anything else: pick Playwright when you can write the steps (known sites, high volume, no per-step model bill), and Browser Use when you can't (unfamiliar or constantly redesigned sites). Their failure modes are opposites: Playwright fails loudly with a stack trace; Browser Use can fail silently, hallucinating plausible data with no warning.
An explicit task plus your own logins fits neither default. That combination is where ego (lite) sits: a free browser built for sharing your logged-in state with agents like Claude Code and Codex, where every site you've signed into stays signed in and the agent works in an isolated Space that never takes your window.
Here's a detail most Browser Use vs Playwright articles miss: Browser Use used to run on Playwright, and left. Since v0.6.0 (August 2025) it drives Chromium directly over CDP with its own typed bindings.
That migration is the comparison in miniature. Playwright is a deterministic code framework built for humans writing repeatable scripts; Browser Use is an LLM agent loop that needed lower-level, faster, more forgiving browser access than a testing framework wants to give.
What's the real difference in positioning?
Playwright is scripted control: you (or your coding agent) write selectors and steps, the framework executes them identically every run, with auto-waiting smoothing the timing. Costs are compute and proxies; there's no per-step model bill. When the site changes a class name, the script breaks, visibly.
Browser Use is delegated control: Agent(task="find the three cheapest flights", llm=...) and the loop perceives, decides, and acts on its own. No selector research, tolerance for redesigned layouts, and a model round trip on every step: capture state, send to LLM, receive action, execute, repeat. Its cloud adds hosted models, proxies, and CAPTCHA handling on top.
Same foundation underneath, two different owners of the decision loop. Everything else in this comparison falls out of that.
The same job in both dialects makes it concrete:
// Playwright: you own the steps
const rows = await page.$$eval('.product', els =>
els.map(e => ({ name: e.querySelector('h3')?.innerText,
price: e.querySelector('.price')?.innerText })))
# Browser Use: the loop owns the steps
agent = Agent(task="List every product name and price on this page",
llm=llm, output_model=Products)
result = await agent.run()Longer but transparent versus shorter but opaque, as the Scrapfly comparison put it. Both lines are true at once.
That's the API on paper. Here's the same task actually run: a real Playwright script and a real Browser Use agent run, both executed against the same page (Hacker News) minutes apart, so the two are directly comparable.
# Playwright: raw Python script, fresh headless Chromium, no login state
from playwright.sync_api import sync_playwright
import time
t0 = time.time()
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto("https://news.ycombinator.com/", wait_until="load", timeout=20000)
title = page.title()
top_story = page.locator(".athing .titleline > a").first.inner_text()
points = page.locator(".subtext .score").first.inner_text()
print({"title": title, "url": page.url, "topStory": top_story, "points": points})
browser.close()
print(f"elapsed_s: {round(time.time()-t0, 2)}")
# Real output:
{'title': 'Hacker News', 'url': 'https://news.ycombinator.com/', 'topStory': 'Qwen 3.8 27B', 'points': '414 points'}
elapsed_s: 1.8# Browser Use: real Agent run, browser-use 0.13.7, gpt-4.1-mini via OPENAI_API_KEY
import asyncio
from browser_use import Agent, ChatOpenAI
async def main():
llm = ChatOpenAI(model="gpt-4.1-mini")
agent = Agent(
task="Go to https://news.ycombinator.com/ and tell me the exact title text of the #1 story on the front page, plus its points count.",
llm=llm,
)
history = await agent.run(max_steps=8)
print("FINAL RESULT:", history.final_result())
asyncio.run(main())
# Real output (trimmed to the meaningful lines):
INFO [Agent] Starting a browser-use agent with version 0.13.7, with provider=openai and model=gpt-4.1-mini
INFO [Agent] ▶️ navigate: url: https://news.ycombinator.com/, new_tab: False
INFO [tools] 🔗 Navigated to https://news.ycombinator.com/
INFO [Agent]
INFO [Agent] 📍 Step 1:
INFO [Agent] 👍 Eval: Successfully located the #1 story title and its points count on the Hacker News front page.
INFO [Agent] 🧠 Memory: Located the top story on Hacker News with title 'Qwen 3.8 27B' and points count '415 points'.
INFO [Agent] 🎯 Next goal: Report the exact title text and points count of the #1 story to the user.
INFO [Agent] ▶️ done: text: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points., success: True, files_to_display: None
INFO [Agent]
📄 Final Result:
The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.
INFO [Agent] ✅ Task completed successfully
FINAL RESULT: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.The points count reads 414 in one run and 415 in the other because Hacker News vote totals change in real time between runs a few minutes apart, not because either number is made up.
Why did Browser Use itself leave Playwright?
Their engineering post on the migration is unusually frank, and worth reading as a review of Playwright from its heaviest user. Three reasons stand out.
Latency: Playwright routes every command through a Node.js relay, which "incurs a meaningful amount of latency when we do thousands of CDP calls" per task.
State drift: with state split across browser, relay, and Python client, "the node.js process can hang indefinitely waiting for a browser reply," and the only fix was kill -9.
Sharp edges: full-page screenshots above ~16,000px "reliably crashes playwright," and of roughly 10 ways tabs crash, "Playwright handled about half of these well, and presented impassible barrier to solving the other half."
The honest reading cuts both ways. For agent infrastructure running thousands of steps per eval, Playwright's abstraction stopped paying for itself. For the rest of us writing dozens-of-steps scripts, those same abstractions (auto-waiting, unified API, cross-browser) are exactly the value, and none of those sharp edges bite at normal scale.
Infrastructure needs differ from user needs.
How do they fail differently?
This is the section that should decide your choice, because you'll spend more time on failures than successes in scraping.
Playwright fails loudly. A broken selector throws a specific, reproducible TimeoutError with a stack trace; you fix the line and the failure never lies to you. The price is brittleness: cosmetic site changes break scripts that were logically fine.
Browser Use fails quietly. The documented risk pattern: when the agent can't find real data, it may produce plausible-looking prices or names with no error or warning, and the field reports match (a user watching it invent "123 Main St" for a form field).
Scrapfly's analysis of the two tools lands on advice worth framing: treat agent output like untrusted user input, validating formats, names, URLs, and empty fields before anything downstream consumes them.
Which tasks belong to which tool?
Choose Playwright when the site is known and stable, volume is high, and cost per run matters: production pipelines, monitoring, regression testing. Choose Browser Use when sites are unfamiliar or frequently redesigned, when the task is research-shaped ("check these 40 vendors for X"), or when nobody's available to write and maintain scripts.
Two boundary cases sharpen the line. A daily price check on one known page is Playwright even though it sounds agent-y: writing the four-line script once beats paying an LLM to rediscover the page daily. A one-time survey across 30 differently-built directory sites is Browser Use even if you're a Playwright expert: thirty scrapers for thirty one-time reads is the wrong trade.
And the fair word for Browser Use's core strength: autonomous navigation of unfamiliar pages is genuinely hard, it's the best-known open-source system for it, and that capability is real even where this article recommends scripts. It's also, notably, a capability ego (lite) deliberately doesn't build; more on that next.
The combined option for logged-in work
Both defaults share a blind spot: your logged-in accounts. Playwright launches clean profiles; Browser Use connecting to a real Chrome profile has been reported unreliable, with the founder acknowledging the instability. Either way, tasks behind your own logins mean scripted auth and its maintenance.
ego (lite) is not a third framework; it combines what each column gets right. From Playwright it keeps explicit, code-written tasks (your agent writes the steps). What it adds is the thing neither column has: the browser is your real, signed-in one.
It's a free browser built for sharing your logged-in browser state with AI agents like Claude Code and Codex; every site you've signed into stays signed in, the agent writes JavaScript through the ego-browser skill so whole workflows run outside the model's context, and it works in an isolated Space that never takes your window.
On complex tasks it finishes up to 3.45x faster than agent-browser, on fewer tokens.
The resulting split, stated as one sentence per tool: Playwright for known public sites at scale, Browser Use for unfamiliar-site autonomy, ego (lite) for explicit tasks behind your own logins.
See the full ego (lite) vs Browser Use comparison, or download ego (lite) for Mac, free.
FAQ
Is Browser Use built on Playwright?
Not anymore. It ran on Playwright until v0.6.0 (August 2025), then moved to direct CDP control with its own typed Python bindings (cdp-use), citing relay latency, cross-runtime state drift, and unhandleable edge cases at agent scale.
Which is cheaper to run?
Playwright, almost always: no LLM calls in the loop, so cost is compute and proxies. Browser Use pays a model round trip per step, with user reports around 50K tokens per step on DOM-heavy pages. The analyses that compare them (Scrapfly's, notably) decline to publish a universal number and recommend logging tokens on your own representative run, which is the right method.
Can I combine Browser Use and Playwright?
Yes, and hybrid is a documented pattern: scripted steps for the predictable parts (login, pagination), the agent for variable-layout extraction, then script-side validation of what the agent returns. It also concentrates the LLM bill on only the steps that need judgment.
Does Browser Use handle CAPTCHAs and bot detection?
Its cloud tier advertises CAPTCHA handling and stealth browsers, while community threads continue reporting CAPTCHA problems as a live issue, so treat it as mitigation rather than a solved problem. On your own accounts, reusing a session you opened in a real browser avoids most of these walls without any stealth machinery.
Which should an AI coding agent like Claude Code use?
If you have a coding agent, it can write the steps, which removes Browser Use's main advantage for explicit tasks: have it write Playwright for public sites, or drive ego (lite) when the task needs your logged-in sessions. Reserve autonomous loops for genuinely unknown territory.