For AI agents

Your agent needs a browser
that isn't obviously a bot.

Real-device fingerprints applied in the engine, identities that persist between runs, and the standard Playwright API your agent already speaks. One line over MCP if it doesn't write code at all.

agent.ts agent.py mcp.json
// 1. install
npm install anti-detect-browser

// 2. launch a fingerprinted profile
import { AntiDetectBrowser } from "anti-detect-browser"

const ab = new AntiDetectBrowser({ key: "your-api-key" })
const { browser, page } = await ab.launch({ profile: "agent-01" })

// 3. …that's it. Plain Playwright from here.
await page.goto("https://example.com")
await page.getByRole("button", { name: "Sign in" }).click()
# 1. install
pip install antibrow

# 2. launch a fingerprinted profile
from antibrow import launch_async

browser = await launch_async(profile="agent-01")

# 3. …that's it. Plain Playwright from here.
page = await browser.new_page()
await page.goto("https://example.com")

# …or hand the CDP url to browser-use, crawl4ai, Scrapling
Agent(task="…", llm=llm, browser=Browser(cdp_url=browser.cdp_url))
// claude_desktop_config.json - or any MCP client
{
  "mcpServers": {
    "anti-detect-browser": {
      "command": "npx",
      "args": ["anti-detect-browser", "--mcp"],
      "env": {
        "ANTI_DETECT_BROWSER_KEY": "your-api-key"
      }
    }
  }
}
// the agent gets: launch, navigate, click, type, read, screenshot
// the browser process survives between tool calls

Two ways in, no third one to learn.

Write code - TypeScript or Python - and you get Playwright handles plus a CDP url for browser-use, crawl4ai or Scrapling. Don't write code and you get MCP tools. There is no proprietary automation API in either direction.

The session outlives the tool call. In MCP mode the browser process keeps running between calls, so an agent can log in on one turn and act on the next.
One profile, two drivers. The identity your agent uses in code is the same one you can open by hand in the desktop app to fix something.
Runs where you run. Your machine, your CI, your box - not a metered cloud browser you rent by the hour.
Recipes

Ask for the data, not for a browser.

A recipe is one file that turns one site into one command. Your agent asks for reddit/hot and gets JSON - no selectors, no scraping code to maintain. Recipes are open source in their own repository and shared by both SDKs.

The same task on N identities. One fanout, four profiles, four personas, four cookie jars, four exit IPs. A task that goes wrong costs a profile, not an account - which is the thing a tool driving your own everyday browser can never offer.
A recipe reaches one site, and only one. It declares the hosts it may touch and the client blocks the rest at the network layer, so community code running in a profile with live logins cannot go shopping in your mail.
Your agent can write them. recipe guide prints the authoring guide, recipe scaffold writes the skeleton, recipe test runs it on a throwaway profile. Point an agent at a site and let it come back with a pull request.
Recipe docs
recipes.sh
// one command, structured JSON - no scraping code
npx anti-detect-browser recipe run reddit/hot --temporary --json

// the same command on four isolated identities
npx anti-detect-browser recipe fanout reddit/hot \
  --profiles 'shopper-*' --concurrency 4 --jq '.items[].title'

// or from the MCP tools: list_recipes / run_recipe / fanout_recipe
Honest comparison

What a stealth plugin doesn't give you.

The real alternative to this product is not another vendor - it's playwright plus a stealth patch, which is free and which we'd use too for a one-off script. Here is the actual difference, so you can decide it's not worth paying for.

Where the spoofing happens

A plugin overwrites properties from JavaScript that runs inside the page. That surface is inspectable, and each Chromium release moves it. AntiBrow applies the fingerprint in the browser engine, below the JS layer, so there is no override script to find.

Identity that persists

Stealth patches randomise per launch. Agents that hold accounts need the opposite: the same machine every time. Each profile keeps its fingerprint, cookies, storage and passkeys on disk, so run 40 looks like run 1.

Passkeys survive re-login

Sites are making passkeys the default sign-in. A profile with its own virtual authenticator captures the enrolment and replays it later, so an agent isn't locked out of an account it registered last week.

Proxy and locale in one move

Bind a proxy to a profile and the timezone, locale and geolocation follow the exit IP automatically. Wiring that yourself is where most hand-rolled stacks contradict themselves.

Someone else's arms race

Detector vendors ship changes continuously. With a plugin, keeping up is your on-call rotation; here it arrives as an engine update. That is most of what you are buying.

What it doesn't fix

Bad proxies, robotic behaviour and a burnt account history will still get you flagged. Nothing on this page changes that, and the free tier exists so you can find out before paying.

Don't take our word for it. Point a fresh profile at the public checks - Whoer.net, CreepJS, or whichever anti-bot wall you actually have to get past - before you wire it into anything that matters. The free tier runs all of them, and the detector runs we published are the same checks you'd be repeating.

Questions, answered.

Those work, they are free, and they will keep working until the next Chromium release moves the goalposts. The difference is who owns that maintenance. AntiBrow applies the fingerprint inside the browser engine rather than patching it from injected JavaScript, and ships the parts a stealth plugin never covers: persistent per-identity profiles, proxy binding with matching timezone and locale, passkey capture and replay, and a concurrency model. If your agent runs one throwaway session a week, keep your plugin. If it maintains identities, that maintenance is the product.

No. The browser runs on your machine or your own infrastructure, and profiles are directories on your disk. There are no browser-hours to buy and no per-session billing; paid plans buy concurrency, optional cloud sync of profiles, managed residential proxies and Live View.

Only the launch line. launch() hands back standard Playwright Page and BrowserContext objects, so every selector, assertion, network intercept and trace you already wrote keeps working. Over MCP there is no code at all - you add one entry to the client config.

Both, and they are the same product rather than a port: anti-detect-browser on npm, antibrow on PyPI, sharing one profile format, one cache directory and one account, so a profile created from Python opens in Node and in the desktop app. The Python package also exposes the raw CDP url, which is what browser-use, crawl4ai and Scrapling want, so those frameworks attach without glue code. Cloud profile sync and Live View are Node and desktop features today; everything else is in both.

Yes, each in its own isolated profile. How many run simultaneously is what your plan sets: 1 on Free, and 5, 20 or 100 on the paid tiers. Profiles themselves are unlimited on every plan.

Both, with the same fingerprint either way. Live View streams a running session to your dashboard on paid plans, which is usually how you debug an agent that has quietly started clicking the wrong thing.

Give the agent a real machine.

Unlimited local profiles, no credit card. Upgrade the day you need more than one browser at a time.

Node 18+ or Python 3.9+ · Windows, macOS & Linux