Comparison

browser.city vs Browserbase (2026): stealth defaults, pricing, and APIs

A practical, engineering-first comparison for teams choosing a browser API for agents, scraping, or automation.

Quick verdict: If you want a polished AI-native platform and don’t mind tiered stealth features and “browser-hours” pricing, Browserbase is a strong incumbent. If you want stealth enabled by default, zero-logs by design, and an API surface that stays simple as you scale (Playwright + Request API + Humanized REST + MCP), browser.city is built for that.

What you’re actually choosing

Both products live in the same category: managed, remote browsers you control via APIs (Playwright/CDP style flows).

The difference is in the defaults:

  • Browserbase optimizes for an AI-native product ecosystem and polished onboarding.
  • browser.city optimizes for infrastructure ergonomics: stealth and privacy as a baseline, and fewer “gotchas” in cost and integration.

At a glance

Dimensionbrowser.cityBrowserbase
StealthOn by defaultStealth features often tiered by plan
Pricing modelTransparent (simple usage model)Browser-hours plans + tiering
API modesPlaywright sessions, Request API, MCP, Humanized REST toolsPrimarily Playwright/CDP-style workflows + SDKs
Privacy postureZero-logs architectureVaries by platform (verify against their docs/security pages)
Best forTeams that want predictable infra primitivesTeams that want an AI-native “platform” experience

Stealth: defaults vs tiers

If your workload hits bot mitigation (Cloudflare / DataDome / PerimeterX / Kasada), the question isn’t “do you have stealth?” but:

  1. Is it enabled by default?
  2. Is it consistent across tiers and environments?
  3. Can you control fingerprint + egress without a matrix of add-ons?

browser.city’s posture is simple: stealth is on. You can still tune sessions (fingerprints, storage state, managed egress, BYOP), but the baseline is designed to work on hostile surfaces.

Pricing: what’s easy to estimate wins

When teams migrate off competitors, the most common reason is not performance, it’s billing complexity:

  • credits vs units vs multipliers
  • stealth priced as an “upgrade”
  • proxy bandwidth billed separately with unclear ratios

Browserbase pricing is generally expressed in browser-hours with tiered plans. That can be totally fine, but you’ll want to model:

  • expected concurrency
  • long-running sessions
  • proxy/bandwidth costs (if separate)

browser.city aims for “you can calculate it in your head” pricing and exposes a Request API for workloads that don’t need full browser orchestration.

API surface: four ways to ship

browser.city intentionally supports four “entry points,” depending on how agentic you need to be:

  1. Request API: fetch a URL and return clean markdown (fastest path to data pipelines).
  2. Sessions API: create a session and connect using Playwright.
  3. Humanized REST tools (/v1/do/*): click/type/markdown over HTTP without running Playwright.
  4. MCP server: give tools to coding agents and AI frameworks without writing glue.

Example: create a session and connect with Playwright:

session.ts
import { chromium } from "playwright";const apiKey = process.env.BROWSERCITY_API_KEY!;const opts = { method: "POST", headers: { Authorization: `Bearer ${apiKey}` } };const session = await fetch("https://api.browser.city/v1/sessions", {  ...opts,  body: JSON.stringify({ browser: "chromium" }),}).then((r) => r.json());const browser = await chromium.connect(session.endpoint, {  headers: { Authorization: `Bearer ${session.token}` },});const [context] = browser.contexts();const [page] = context.pages();await page.goto("https://example.com");

When to pick which

Choose Browserbase if:

  • you want an AI-first product suite and polished platform UX
  • you’re already invested in their SDK ecosystem
  • you’re OK with stealth/compliance features being plan-gated

Choose browser.city if:

  • you want stealth by default with fewer configuration “traps”
  • you care about a zero-logs posture as an architectural constraint
  • you want multiple integration styles (Request API, Playwright sessions, Humanized REST, MCP tools) without switching products

Migration notes (Browserbase → browser.city)

Most migrations are mechanical:

  1. Swap session creation to POST /v1/sessions
  2. Keep your Playwright code, but connect using the returned endpoint and token header
  3. For “fetch + extract” flows, replace agent loops with POST /v1/requests or POST /v1/requests/batch

If you want help mapping your current flows (sessions, egress, and fingerprint strategy), start with the Integrations hub and pick your toolchain.

[ 06 / 06 ] — Get Started

Start building in under a minute

Free tier. No credit card. Full stealth from day one.