Browserbase is browser infrastructure and String is page retrieval. Browserbase sells hosted Chrome sessions for agents that click, log in, and fill forms, plus a lighter Fetch API for reading pages. String sells one fetch endpoint that gets protected pages back. On the open Web Data Frontier Benchmark of 100 bot-protected sites, 5 attempts each (September 16, 2026), String returned verified content on 97.0% of requests and Browserbase's Fetch API, with proxies on, returned 41.4%. On the failure-aware latency score, String posted 7.06 seconds (first of 16 providers) and Browserbase 17.73 (eighth). Browserbase returned nothing on 55 of the 100 sites, the most of any provider in the run; String passed 50 of those 55 on every attempt. Both passed all 40 social-platform requests. Pick Browserbase when the task is a browser task: a login, a form, a multi-step flow an agent has to drive. Pick String when the task is reading a page that fights back.
TL;DR
| String | Browserbase | |
|---|---|---|
| Product type | Unblocker: fetch, search, sitemap, remote browser over CDP | Browser infrastructure: hosted browser sessions, agents, Fetch, Search, Extract |
| Benchmark success rate | 97.0% (485/500) | 41.4% (207/500), Fetch API with proxies |
| Latency score, all 16 providers | 7.06s (1st) | 17.73s (8th) |
| Sites where nothing came back | 2 of 100 | 55 of 100 |
| Social platforms (8 targets) | 40/40 | 40/40 |
| Pricing basis | Pay per successful request; rate set by the proxy and fetch path the page needed; credits roll over | Subscription plus per-call Fetch ($1 or $0.50 per 1,000; $4 with proxies), browser hours ($0.10 to $0.12 per hour overage), proxy bandwidth ($10 to $12 per GB) |
| Browser support | Browser fetch path billed per request; /wss remote Chrome over CDP | Core product: hosted Chrome sessions, up to 250+ concurrent on Scale, Stagehand framework |
| JS rendering | Yes, selected per request | Yes, in browser sessions; Fetch is the lightweight path |
| Anti-bot coverage (benchmark) | 100% Cloudflare, Kasada, Fastly; 98% Akamai; 98% DataDome; 89% PerimeterX | 11% Cloudflare; 22% Akamai; 45% DataDome; 53% PerimeterX; 33% Kasada |
| MCP and agent integrations | Registry ai.usestring/web-access, hosted at mcp.usestring.ai; fetch, search, sitemap tools |
MCP server, Stagehand, agent SDKs, hosted runtime functions |
| Where it wins | Protected pages; pay-on-success billing; latency score | Interactive browser work; social platforms (tie); news and finance; SOC 2 on every plan, HIPAA on Scale |
We built the Web Data Frontier Benchmark and we sell the product that ranks first in it. The answer to that conflict is a test you can run yourself: the harness, the 100 target URLs, the pass criteria, and every provider's adapter are public, and the repo takes your own API keys. Providers have used that path: a Firecrawl engineer corrected our Firecrawl adapter in July, and the September run corrected our ScraperAPI and ScrapingBee adapters, moving those two by 19.8 and 43.3 points. Browserbase can do the same.
The Browserbase adapter matters here, so read it before you read the numbers. It calls Browserbase's Fetch API with proxies: true, which is the product shape closest to String's fetch endpoint and the path Browserbase's own docs recommend for reading a page you do not need to interact with. It does not open a browser session, and it does not use the Verified fingerprints Browserbase reserves for its Scale plan. A browser session might clear more of these sites. It would also cost browser hours instead of a per-call fee. If Browserbase believes a different configuration is fairer, the adapter is one short file and a pull request changes it.
Every figure below comes from the run's results JSON. Pricing and billing terms were checked against both companies' live pages on August 29, 2026.
Browserbase is a platform for running browsers in the cloud: browser sessions with live view and recordings, an agents layer, a hosted runtime for functions, a Search API for finding pages, a Fetch API for reading them without a browser, an Extract API, and an identity layer of proxies, contexts, and Verified fingerprints. It maintains Stagehand, an open-source browser automation framework, and ships an MCP server. If your agent has to log in, click through a wizard, or fill a form, this is the tooling built for it.
String is one endpoint. Send a URL, get the page back as markdown, HTML, or JSON. Proxy rotation, fingerprinting, captcha solving, and retries happen behind the endpoint. There is a /search endpoint for live Google results, an asynchronous sitemap crawl, a /wss endpoint for a remote browser over CDP when you need one, and an MCP server at mcp.usestring.ai. String does not sell a browser-agent platform. Browserbase has more product; String holds up on pages that fight back.
Browserbase's own writing draws the same line. Its post on choosing between Search, Fetch, and Browser says to use Fetch when you do not need to click, scroll, or log in, and that reliable agent teams "do as much as possible with lightweight primitives" and reach for a browser only when the page demands one. The benchmark measures the lightweight primitive.
The benchmark sends 16 providers the same 100 URLs, 5 attempts each, every provider in its strongest fetch mode: 8,000 live billable requests. A request passes only when the response contains a marker from the real page, such as a product title. A captcha page that returns HTTP 200 counts as a failure. Most targets are bot-protected retail, travel, news, and social sites.
| Provider | Success rate | Latency score |
|---|---|---|
| String | 97.0% | 7.06s |
| Scrapfly | 86.2% | 19.79s |
| ScraperAPI | 84.0% | 12.97s |
| Firecrawl | 80.2% | 9.11s |
| Apify | 77.4% | 20.64s |
| Bright Data | 74.6% | 15.62s |
| ScrapingBee | 73.0% | 21.96s |
| Context.dev | 72.0% | 16.32s |
| Oxylabs | 69.0% | 15.86s |
| Nimble | 68.6% | 21.54s |
| Zyte | 68.0% | 17.46s |
| Browserbase | 41.4% | 17.73s |
The latency score is a per-target p75 of successful attempts. A provider that returns nothing on a target inherits the p75 of the providers that did succeed there, and if nobody succeeds the target scores the 90-second timeout. The score refuses to reward fast failures. Browserbase's 17.73 seconds is eighth of 16, mid-field, and String's 7.06 leads the run; Firecrawl follows at 9.11.
This benchmark measures one thing: whether a fetch returns the real page from a protected site. It does not measure what Browserbase is mostly bought for, which is running an agent through a multi-step browser task. Browserbase publishes its own reliability figures for that work on its site; they come from Browserbase's own runs, and this page does not use them.
The 41.4% average hides where the failures sit. Per target, Browserbase's Fetch API is either fine or absent.
| Per-target outcome (100 sites) | String | Browserbase |
|---|---|---|
| Passed all 5 attempts | 93 | 36 |
| Passed some attempts | 5 | 9 |
| Passed none | 2 | 55 |
The 55 sites where Browserbase returned nothing on any attempt include Walmart, Home Depot, Lowe's, Best Buy, Kroger, eBay, Nike, Lululemon, Zara, Louis Vuitton, Saks Fifth Avenue, Ralph Lauren, StockX, Yelp, G2, Capterra, Trustpilot, Glassdoor, ZipRecruiter, Realtor.com, Apartments.com, Zoopla, Idealista, Tripadvisor, Kayak, Delta, American Airlines, Hyatt, Booking.com, AutoZone, StubHub, AXS, Crunchbase, DigiKey, Roblox, GitHub, and Stack Overflow. String passed 50 of the 55 on all five attempts. The other five were String's own weak spots: Allegro and Coupang at 4 of 5, and Temu and Idealista at 0 of 5, the two sites that shut out both providers.
Browserbase beat String on no target in this run. That is unusual in these comparisons; Firecrawl and Bright Data each won at least one site. It is also a Fetch API result, not a browser-session result.
Browserbase's proxy documentation says its built-in residential proxies come from third-party providers, and that those providers restrict certain site categories under their own acceptable-use rules. Browserbase names the categories: banking and financial services, government domains including most .gov sites, streaming and entertainment, ticketing, webmail, and gambling. It adds that support "isn't a blanket yes/no per site" and tells you to test your own targets first.
Four results on this page sit inside those categories. Congress.gov is a .gov domain and returned 1 of 5. StubHub and AXS are ticketing and returned nothing. That is worth saying plainly: on those targets the benchmark is measuring a proxy-provider policy, not a limit of Browserbase's engineering. It is also worth saying that the distinction does not help a buyer whose target list includes ticketing or government pages, because the pages still do not come back.
Fifteen of the 100 targets sit behind Cloudflare. String passed all 75 requests against them. Browserbase's Fetch API passed 6 of 75, or 8.0%. Akamai is similar: 28.0% for Browserbase across 20 targets, 98.0% for String. DataDome, the largest named column at 19 targets, is 29.5% to 92.6%. The only anti-bot vendor where Browserbase clears more than half its requests is PerimeterX, at 57.8%, where String returned every request.
For anyone whose target list is retail, fashion, or travel, this is the evaluation. Those industries are where Cloudflare, Akamai, and DataDome live, and the industry cut says the same thing: fashion and luxury 18% to 98%, travel 13% to 87%, retail and ecommerce 40% to 91%, reviews and local 0% to 100%.
Eight of the 100 targets are social platforms: LinkedIn, X, Instagram, Reddit, TikTok, Facebook, Pinterest, and YouTube. Both providers passed all 40 requests. Firecrawl, by contrast, passed 10 of 40 and blocks several of these platforms by policy. If public social pages are your workload, Browserbase's Fetch API is a credible option, and String's advantage over it is elsewhere.
The 49 shutouts are visible within an hour of testing. The more expensive problem is the 15 sites where Browserbase passed some attempts and failed others:
| Target | Browserbase | String |
|---|---|---|
| Indeed | 1/5 | 5/5 |
| Asda | 1/5 | 5/5 |
| Etsy | 1/5 | 5/5 |
| Expedia | 1/5 | 5/5 |
| Reuters | 1/5 | 5/5 |
| eBay | 1/5 | 5/5 |
| Congress.gov | 1/5 | 5/5 |
| Ashley Furniture | 2/5 | 5/5 |
| Google Search | 2/5 | 5/5 |
| Barron's | 3/5 | 5/5 |
| Zillow | 4/5 | 5/5 |
| MarketWatch | 4/5 | 5/5 |
| Bloomberg | 4/5 | 5/5 |
| GoodRx | 4/5 | 5/5 |
| Leboncoin | 4/5 | 5/5 |
A scheduled job that clears Reuters one attempt in five looks alive in monitoring while it starves the dataset: gaps in time series, values that appear to move because a scrape silently missed. Retries paper over the problem and inflate the bill, and Browserbase bills Fetch per call.
String's latency score of 7.06 seconds leads the run; Browserbase's 17.73 is eighth of 16. The score charges a provider for the targets it fails, and Browserbase failed more of the suite than any other provider, so its score is not a measure of how fast a Browserbase fetch is when it works. On the 34 sites both products returned in full, the median per-site time was 1.60 seconds for String and 2.00 for Browserbase, which is close. On the pages it does return, a Fetch call is a lightweight HTTP path and is quick. If speed on cooperative pages is your question, both products are fast enough that success rate should decide it.
Browserbase sells a subscription with allocations and pay-as-you-go overage. Free is $0 with 1 browser hour, 1,000 Fetch calls, and no proxies. Developer is $20 a month with 100 browser hours (then $0.12 per hour), 1 GB of proxy bandwidth (then $12 per GB), 25 concurrent browsers, and 1,000 Fetch calls, then $1 per 1,000. Startup is $99 with 500 browser hours (then $0.10 per hour), 5 GB of proxies (then $10 per GB), 100 concurrent browsers, and 10,000 Fetch calls, then $0.50 per 1,000. Fetch through proxies costs $4 per 1,000 calls on both paid plans, and proxies are what protected sites need. Search is $7 per 1,000 after the first 1,000. Verified fingerprints and 250+ concurrency are on the custom Scale plan.
String sells usage on top of a small subscription. The first 5,000 requests are free. Starter is $20 a month, Growth is $100. The per-request rate depends on what the page actually needed:
| Fetch path and proxy | Starter, per 1,000 | Growth, per 1,000 |
|---|---|---|
| Request-based, standard proxy | $0.30 | $0.20 |
| Request-based, premium proxy | $3.00 | $2.00 |
| Browser-based, standard proxy | $1.50 | $1.00 |
| Browser-based, premium proxy | $6.00 | $4.00 |
Credits roll over on every plan, and a blocked request is never billed.
On the headline rate, Browserbase's proxied Fetch at $4 per 1,000 calls is the same number as String Growth's browser-on-premium-proxy path, and above String's other three paths. The fairer unit is cost per 1,000 usable pages, which folds in the benchmark pass rate. At 100,000 requests a month against the benchmark suite:
| Billing assumption | Cost per 1,000 usable pages | |
|---|---|---|
| Browserbase Startup, Fetch with proxies | $99 plus $4 per 1,000 calls; 41.4% return content; every call bills | $12.05 |
| Browserbase Startup, Fetch with proxies, if the 10,000 included calls apply | $99 plus $4 per 1,000 for 90,000 calls | $10.88 |
| String Growth, standard request | $100 plus $0.20 per 1,000 successes; 97.0% return content; failures free | $1.23 |
| String Growth, premium request | $100 plus $2.00 per 1,000 successes | $3.03 |
| String Growth, browser on premium proxy | $100 plus $4.00 per 1,000 successes | $5.03 |
Two caveats on that table, both in Browserbase's favor. Browserbase's billing pages price Fetch per call throughout, never per successful call, and as of August 29, 2026 they name no exclusion for a fetch that fails or comes back blocked. So the table assumes every call bills. That is what their published terms say rather than something they state outright, and if Browserbase does credit failed fetches, its numbers fall. The second caveat is that a Browserbase browser session, billed in browser hours, is a different product with a different pass rate that this benchmark did not measure. What the table does say is that on protected pages the Fetch API's price per usable page is set by its 41.4% pass rate, and no plan tier changes that.
The risk asymmetry follows from that reading: on published terms your evaluation bills at $4 per 1,000 calls whether or not the page comes back. String's evaluation bills nothing for a block, and the first 5,000 requests are free.
One throughput note that does not show up in a price table. Browserbase caps Fetch at 5 requests per second per project on every plan, Free through Startup, with a custom rate only on Scale. At that ceiling, 100,000 pages takes about five and a half hours of continuous calling even if every call succeeds. If your workload is a nightly bulk read, check that number against your window before you check the price.
Browserbase's own guidance is Search, then Fetch, then Browser only when needed. Replacing the Fetch step with String is a one-line change: POST to https://request.usestring.ai/v1/fetch with {"url": "..."} and markdown comes back by default. Keep Browserbase for the sessions that need a real browser and an agent driving it. Running both is a reasonable end state, and the first 5,000 String requests are free, which covers testing your own list of the pages that currently fail.
Browserbase is browser infrastructure: hosted Chrome sessions for agents that click, log in, and fill forms, plus Fetch and Search APIs for reading and finding pages. String is a fetch endpoint that gets protected pages back and bills only when content returns. On the open Web Data Frontier Benchmark (100 bot-protected sites, September 2026), String passed 97.0% of requests and Browserbase's Fetch API, with proxies, passed 41.4%.
For pages that need interaction, yes; that is what it is built for. For bulk reads of protected pages, the benchmark says no: Browserbase's Fetch API returned nothing on 55 of 100 bot-protected sites, the most of any provider in the run, and passed 8.0% of requests against Cloudflare-protected targets. Browserbase's own guidance is to use Fetch for simple pages and a browser only when the page demands one.
Not through its Fetch API in this run. On 15 Cloudflare-protected targets, Browserbase passed 8 of 75 requests; String passed 75 of 75. Akamai was 22% to 98% and DataDome 45% to 98%. A Browserbase browser session with Verified fingerprints (Scale plan) was not tested.
Usually not. The benchmark's top providers, String at 97.0% and Scrapfly at 86.2%, are fetch APIs that decide per request whether a page needs a browser. String bills the browser path only when it used one ($1.00 to $4.00 per 1,000 on Growth) and the plain-fetch path otherwise ($0.20). You need a browser you control when the task is interaction, and that is Browserbase's product.
Not for reading protected pages. Browserbase's Fetch API is $1 or $0.50 per 1,000 calls without proxies and $4 per 1,000 with them, on top of a $20 or $99 subscription. String Growth is $0.20 per 1,000 for a plain fetch and $1.00 to $4.00 when a page needs a browser or a premium proxy. Per usable page at 100,000 requests a month against the benchmark suite, Browserbase's proxied Fetch works out to about $11 to $12 per 1,000 at its 41.4% pass rate; String's plain-fetch path is $1.23 and its most expensive path $5.03. For browser sessions, Browserbase bills hours ($0.10 to $0.12 per hour overage), which is a different unit and a different job.
Browserbase prices Fetch per call ($1, $0.50, or $4 per 1,000) and browser sessions per hour; its docs describe allocations and overage, not a success-only rule. String bills only requests that return verified content, so a block costs nothing.
When the job is a browser job: authenticated flows, forms, multi-step interactions, pages whose content only appears after a click, or an agent that has to act rather than read. Browserbase's sessions, Stagehand, contexts, and Verified fingerprints are built for that, and its Fetch API passed every social-platform request in the benchmark. Use String when the job is getting a protected page back reliably.
Run the benchmark. The harness, 99 target URLs, pass criteria, and per-provider adapters, including the Browserbase adapter that calls Fetch with proxies, are public at github.com/usestring/web-data-frontier-benchmark, and it takes your own API keys. A full run makes thousands of billable calls, so start with a subset. If your numbers differ, or if Browserbase's team thinks a different configuration is fairer, open a pull request; Firecrawl did, and their score went up.
