Headless Browser vs Real Browser for AI Agents

The core conclusion first, because most readers won't scroll: anything behind your logins or facing hardened anti-bot defenses belongs in a real browser, and batch, stateless work (bulk crawls of public pages, PDF generation, CI checks) belongs in a headless one.

Within the real-browser lane, the strongest daily setup is ego (lite): it shares your everyday browser's logins with the agent inside an isolated workspace, so login-walled tasks run without handing over the window you work in, and it's free. Public-data scraping at scale stays headless, where paying for a real browser is waste.

The terms, for anyone landing cold: a headless browser runs the same engine with no visible window, driven entirely by code. A real browser is the one a person actually uses, real profile and sessions included; in automation jargon it is headed (a window is rendered), but a headed automation browser with a fresh profile is not yet real.

Everything below is the evidence: the concrete tools on each side by name starting with the real-browser side, then the three deciding dimensions in depth (logins, detection, cost), and a task table you can pick from directly.

Match the browser to the task, not to a preference.

How do you decide: real browser or headless?

The question sounds binary and mostly is, but the boundary runs through the task, not the tooling. Both modes drive the same engines (Chromium, Firefox, WebKit) through the same automation protocols, so capability isn't the differentiator.

Three things are: whether your logins come along, how visible the automation is to a defending site, and what a running instance costs. The table below is the summary; the tools come next, and each dimension gets its own deep dive after them.

One clarification that saves confusion: headless is not a synonym for "detectable" and real is not a synonym for "safe." A real browser driven badly (impossible speeds, robotic paths) gets flagged, and a modern headless setup on public pages sails through. The modes set a baseline; behavior moves you off it in either direction.

The whole split in one look, before any detail. Find the row your task cares about most; the winner in that row is your browser.

The real-browser tools, by name

The real-browser side has its own concrete roster, and it sorts into four families by how the agent reaches the browser: a shared-session browser built for the job, attach routes into the Chrome you already run, vendor extensions, and no-code recorders.

ego (lite)

ego (lite) (free) is the shared-session browser family, and it's our own product, stated plainly. Import from Chrome once and every site you've signed into stays signed in; the agent works in an isolated Space with its own tabs, driven by any agent that can run a shell command through the ego-browser skill.

On complex tasks it finishes up to 3.45x faster than agent-browser, on fewer tokens. It's the only entry in this roster that gives the agent real sessions without giving it your window.

What that isolated Space actually returns, run today against a live page: a real ego-browser session opens a task, navigates, and comes back with only the fields asked for, no accessibility-tree dump attached.

const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)

{
  "taskSpaceId": 13
}
{
  "title": "Hacker News",
  "url": "https://news.ycombinator.com/",
  "topStory": "Qwen 3.8 27B",
  "points": "412 points"
}

Download ego (lite) for Mac, free, or see the full session model in the logged-in browser guide.

Chrome DevTools MCP auto-connect

Chrome DevTools MCP auto-connect (Google, free) is the official attach route: on Chrome 144+, enable remote debugging at chrome://inspect, add the --autoConnect flag, and the agent operates inside your signed-in Chrome after a per-session permission dialog. Full sessions, real fingerprint, plus the debugging toolkit nothing else has; the cost is that it's your window being driven while it works.

Browser MCP

Browser MCP (browsermcp.io, free) is the community attach route: an extension-plus-server pair that connects Cursor, Claude, VS Code, and other MCP clients to your existing browser. Automation runs locally, uses your existing profile so your logins come along, and rides your real fingerprint; like every attach route, it drives the browser you're using, one task at a time.

Claude in Chrome and Codex for Chrome

Claude in Chrome and Codex for Chrome are the vendor-extension family: Anthropic's reads the page you're signed in to, then clicks, types, and fills forms, on all paid Claude plans; OpenAI's acts on sites where you're already signed in (its docs name LinkedIn, Salesforce, Gmail) with tasks grouped into Chrome tab groups.

Zero technical setup, mature per-site permission prompts, and two shared costs: each serves only its own vendor's agent, and each works in your window.

Axiom, Browse AI, and Simplescraper

Axiom, Browse AI, and Simplescraper are the no-code family: point-and-click recorders that capture a login-and-extract flow in a real browser session and replay it on a schedule. For a non-developer pulling one table from one portal they're the fastest first result on this page; the trade is brittleness when the site redesigns, and a hosted runner carrying your session on someone else's infrastructure.

Read the trade column and the pattern is visible: everything except the first row either borrows your window or ships your session somewhere. That's the structural reason the shared-session family exists at all.

The headless tools, by name

"Go headless" is a category, not a decision, so here's the category by name. It splits into three tiers: libraries you script against, tools built for agents specifically, and cloud fleets you rent when one machine stops being enough.

Playwright

Playwright (Microsoft, 90K+ GitHub stars) is the default library tier answer. One API drives Chromium, Firefox, and WebKit with full parity. Its four official language families are Node.js (JavaScript/TypeScript), Python, Java, and .NET/C#, and auto-waiting actionability checks make scripts stable without hand-written sleeps.

Headless is its native habitat in CI, and for agent use there's Playwright MCP on top of the same engine.

Puppeteer

Puppeteer (Google's Chrome DevTools team, 95K+ stars) is the lean, Chrome-first alternative: JavaScript and TypeScript only, Firefox support in beta via WebDriver BiDi, no WebKit. Where it wins is simplicity per task: PDF generation, screenshots, and straightforward crawls with minimal overhead, which is why plenty of scraping fleets still standardize on it.

Selenium

Selenium is the oldest survivor and the compatibility net. Its documentation lists five language bindings: Java, Python, C#, Ruby, and JavaScript. It also offers broad WebDriver coverage and Selenium Grid for distributing a suite across machines. Its WebDriver protocol adds an HTTP hop per command that the CDP-native tools skip, so it's rarely the pick for new scraping work, but nothing matches its reach across an existing test estate.

agent-browser

agent-browser (Vercel Labs, ~40K stars, Apache-2.0) is what the agent-native tier looks like: a Rust CLI with a daemon speaking raw CDP, driving a downloaded Chrome for Testing. The agent runs agent-browser snapshot to get an accessibility tree with refs like @e1, then acts on them with commands like click @e2. Sessions are deliberately isolated, output is filterable to stay token-lean, and the whole design assumes no human is watching.

Browser Use

Browser Use (MIT, ~109K stars) belongs in this list with an asterisk: it's an autonomous Python framework rather than a browser, but it runs its perceive-decide-act loop over direct CDP in a browser it manages, and its headless toggle is exactly the switch this article is about. Run it headless for goal-driven scraping at scale; run it headed when the target fights back.

Here's that perceive-decide-act loop actually running: a real Agent (browser-use 0.13.7, gpt-4.1-mini via OPENAI_API_KEY) against a live page today, headless, real LLM tokens spent.

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)

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] 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
Final Result:
The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.
INFO     [Agent] Task completed successfully

Browserbase and Stagehand

When the fleet outgrows your machine, the cloud tier takes over. Browserbase sells managed browser infrastructure at the scale of thousands of concurrent sessions (36.9M unique sessions in a March 2026 monthly count, 10,000+ companies), with Stagehand (23.7K stars) as its open-source SDK layering act, extract, and observe primitives over Playwright-style code.

Browserless

Browserless plays the same position with an API-first shape: REST endpoints for /screenshot, /pdf, /content, and /scrape, an /unblock endpoint for bot-detection handling, and BrowserQL for multi-step flows, callable from anything that can send an HTTP request, n8n workflows included.

The stealth layer

And one honest layer on top: the stealth ecosystem. Selenium has undetected-chromedriver and SeleniumBase; Puppeteer's puppeteer-extra-plugin-stealth is the mature classic, and playwright-extra can load its plugins; Camoufox and Patchright currently support only Playwright. Treat all of it as a moving target rather than a purchase: practitioners on r/webscraping report cases where a stealth fork got blocked while default Playwright passed.

Seven names, one shared operational cost: each defaults to fresh or separately managed browser state. Sessions can be injected or persisted, but they require setup, protection, refresh, and debugging. If that is the wall your tasks keep hitting, the real-browser roster above is the answer; if it isn't, these seven remain the lighter automation lane.

Which one has your logins?

Headless does not mean login-free. A fresh context starts empty, but Playwright can restore authentication through storageState or a persistent profile. The real difference is how much work it takes to prepare that state, reuse it, and recover after the server expires it.

On August 21, 2026, we ran each path five times against the same first-party login fixture on an M4 Mac. Playwright 1.59.1 used Chromium 147; ego (lite) was 0.4.7.1.

All four paths completed five of five runs without a retry. With a session ready, a fresh ego (lite) Space reached the protected page in 0.43 seconds, versus 1.42 to 1.61 seconds for Playwright. Reusing any session also gives the agent that account's permissions.

Zillow stays a field observation

In a separate read-only run, fresh Playwright stopped at Zillow's Press & Hold screen, while ego (lite) with an inherited session reached the homepage and account menu. Read Zillow's current terms before automating. Login state, automation signals, defenses, and profile history changed together, so this remains a field observation rather than a causal benchmark.

How big is the detection gap?

Less different than it used to be, and the reason is a specific change. Chrome shipped a new headless mode (--headless=new) that runs the same browser binary as the visible one, replacing the old separate headless implementation that leaked obvious tells.

Under the old mode, sites caught headless instances on things like a HeadlessChrome token in the user agent, missing plugin and MIME arrays, and a stripped-down rendering path. The new mode closes most of those, because there's no longer a separate, thinner browser to catch.

What still leaks is subtler and rarely lives in the user agent. Automation flags (navigator.webdriver set true unless suppressed), the absence of a real display and its device-scale quirks, timing and interaction patterns no human produces, and connection signals from datacenter IPs all remain visible to a determined defender.

Detection in 2026 is a scoring problem, not a single check: no one signal condemns you, but a stack of them does. That's why the honest framing is baseline plus behavior, not headless-bad, real-good.

Our three-mode detection test

We also opened Sannysoft's public detector in three modes on the same Apple M4 Mac and network: Playwright 1.62.1 default headless Chromium, Playwright headed Chromium with a fresh profile, and ego (lite)'s persistent real browser. Each mode was repeated three times, and the visible signals below were stable across those repetitions.

The practical result is narrower than ‘headed beats headless.’ Making Playwright visible removed several environment differences, but the fresh headed run still exposed WebDriver. The persistent ego (lite) run more closely matched the installed desktop environment on this page. A defending site can also use IP reputation, request patterns, interaction timing, account history, and private signals that this test never saw.

There is another important version detail: Playwright distinguishes its default Chromium headless shell from the newer headless mode available through the Chromium channel. Our default-headless result must not be generalized to every modern Chrome headless configuration. If detection matters, record the exact package, browser build, launch channel, flags, profile, network, and date.

What the tools felt like to run

Playwright was the cleaner choice for a controlled fresh-context test. The browser version and launch mode were explicit, the run could be repeated, and the screenshot was easy to capture at a fixed viewport. The friction appeared when the task crossed into account state: headed mode gave us a window, but the fresh profile was still fresh. We would need to authenticate, import state, or maintain a persistent profile before doing useful account work.

ego-browser took a different approach: it created an isolated Space and opened YC Hacker News inside ego (lite). The screenshot below shows the actual run, including the browser chrome, the agent's Browsing Hacker News cursor, and the live control panel. The agent works in its own tabs while the user can watch progress, take over, or stop the task at any time.

That experience also made the split between the products clearer. We would use a fresh Playwright context when a public test needs a controlled, disposable environment. When the task depends on an authorized existing session, an isolated ego (lite) Space skips profile recreation and lets the agent begin from the state the user already prepared.

What does each cost to run?

We ran five cold starts per mode on the same M4 Mac and first-party page. Playwright 1.59.1 used Chromium 147; ego (lite) was 0.4.7.1. We recorded time, RSS, retries, and failures.

The default shell was the leanest full Playwright process tree at 263 MB loaded. New headless and headed reached 627 and 641 MB, only 2.2% apart. The ego (lite) Space started fastest and added 178 MB of Space processes; its row excludes the running shared app, GPU, and network processes. All 20 runs succeeded without retries.

End-to-end agent cost adds another layer. In our 31-task real-world benchmark, run with the same model and judge, ego-browser recorded the lowest average cost per task in its best complete round at $1.92. Playwright CLI recorded $3.27 and Chrome DevTools CLI recorded $4.95 under the same setup.

Which browser for which task?

The three dimensions collapse into a task lookup. Find the row that matches what you're actually doing; the pull is rarely ambiguous once the task is named honestly.

The composite most real setups reach: headless for the fleet of stateless jobs, a real browser for the login-walled and defended ones, and no attempt to force one mode to do the other's job. The failure pattern is picking a mode for taste ("headless feels lighter," "a real browser feels safer") and then fighting your own choice on every task that doesn't fit it.

FAQ

What is the best headless browser for AI agents?

For most agent work it's headless Chromium driven by Playwright, because it has broad tooling, four official language families, and access to modern Chromium headless modes; Puppeteer is the leaner pick for Chrome-only jobs, and agent-browser is the CLI built for agents specifically. Firefox and WebKit headless matter when you need cross-engine coverage.

"Best" is task-shaped: the right headless browser for CI checks and the right one for evading a hardened target can differ, and for the hardened target the better answer is often a real browser.

Is a browser like ego (lite) called a headed browser or a real browser?

Both descriptions are useful, but real browser is not a formal industry category. Headed only says a window is rendered, and a Playwright-launched headed Chromium can still use a fresh automation profile. In this article, real browser means the ordinary persistent browser environment a person uses: an installed profile, live sessions, and the surrounding desktop environment. ego (lite) fits that practical definition because it can inherit authorized Chrome sessions inside an isolated Space.

Can websites detect a headless browser?

Yes, but less easily than before. Chrome's new headless mode removed the obvious tells (the HeadlessChrome user-agent token, missing plugin arrays), so detection now leans on automation flags, environment signals like the absence of a display, and behavioral patterns. It's a scoring stack, not one check, which is why a well-configured headless setup passes on public pages while a careless one still gets caught.

Should Browser Use run headless or not?

It depends on the task, and the toggle exists for exactly that. Run it headless for stateless scraping and CI-style jobs where cost and speed win. Run it headed (or on a real-browser setup) when the target is login-walled or heavily defended, where a visible, session-carrying browser is worth the resource cost. The framework supports both; the task should decide which.

Is a real browser always safer from bans?

No. A real browser lowers the baseline detection surface, but bans track behavior: volume, speed, and access patterns no human produces get flagged in any browser. A real browser driven abusively is more detectable than a careful headless crawler on public data. The browser sets the floor; how you behave decides whether you stay on it.

Does headless mean faster?

Usually per-instance and at scale, yes, because there's no window to render and instances pack densely for parallel work. For a single interactive task the difference is marginal, and any speed edge disappears if the site blocks the headless instance and you have to retry. Headless is faster where its economics apply (many stateless jobs), not universally.

Can I share my logins with a headless browser?

Yes. Playwright can load a saved authentication state, add cookies, or launch a persistent context, but that state must be created, protected, refreshed, and debugged as it expires. If an existing authorized login is the point, a real-browser tool that inherits the user's session inside an isolated Space can remove the injection step, at the cost of being a desktop browser rather than a CI-friendly headless one.

What is the difference between a headless browser and a real browser?

A headless browser runs without a visible window and is well suited to scripted, parallel work on servers. In this article, a real browser means an ordinary persistent desktop browser environment with a user-authorized profile and live sessions. The practical divide is often state management: fresh automation contexts begin empty, while an existing persistent session is already prepared.

Do stealth plugins make a headless browser undetectable?

No. Plugins like puppeteer-extra-plugin-stealth or forks like Camoufox and Patchright suppress known signals, but detection is a moving target and practitioners report cases where a stealth fork got blocked while default Playwright passed. Stealth lowers a score; it doesn't buy invisibility. When the target is hardened and the task is yours to run legitimately, a real browser with real sessions sidesteps the arms race instead of joining it.

Choose the next step

If your choice is between a fresh Playwright workflow and an isolated session-carrying browser, read the ego (lite) vs Playwright comparison. If the task needs an existing authorized login, download ego (lite) and start in a separate Space rather than handing an agent your active browser window.