The Web Data Frontier Benchmark
Last updated August 11, 2026 · rerun regularly
Every web scraping vendor advertises a success rate between 98% and 100%, and they cannot all be right. So we built a test anyone can run. The Web Data Frontier Benchmark sends 15 providers the same 99 bot-protected websites, 5 attempts each, 7,425 live billable requests in total. In the run completed August 11, 2026, success rates ran from 29.7% to 97.0%. String placed first at 97.0%, 480 of 495 requests. The harness, the target list, the pass criteria, and every provider’s adapter are public, and the repository accepts your own API keys.
The current leaderboard
Every provider, every target, same harness, same window. Numbers below come verbatim from the run completed August 11, 2026. Treat them as a snapshot of that date rather than a permanent ranking; the whole point of rerunning is that they move.
| Rank | Provider | Success rate | Latency score | Passed |
|---|---|---|---|---|
| 1 | String | 97.0% | 9.98s | 480/495 |
| 2 | Scrapfly | 82.0% | 18.35s | 406/495 |
| 3 | Context.dev | 79.2% | 12.68s | 392/495 |
| 4 | Firecrawl | 78.6% | 9.21s | 389/495 |
| 5 | Bright | 78.0% | 26.14s | 386/495 |
| 6 | Oxylabs | 76.8% | 14.67s | 380/495 |
| 7 | Zyte | 72.7% | 14.85s | 360/495 |
| 8 | Decodo | 70.7% | 22.63s | 350/495 |
| 9 | Nimble | 66.3% | 18.41s | 328/495 |
| 10 | ScraperAPI | 64.2% | 13.65s | 318/495 |
| 11 | Scrapingdog | 54.3% | 12.51s | 269/495 |
| 12 | Browserbase | 42.2% | 14.19s | 209/495 |
| 13 | ZenRows | 34.3% | 17.60s | 170/495 |
| 14 | ScrapingAnt | 30.7% | 16.08s | 152/495 |
| 15 | ScrapingBee | 29.7% | 16.97s | 147/495 |
How it works
Every provider receives the same 99 URLs and runs in its strongest anti-bot configuration. The request shape for each one lives in an adapter file in the repository, so the configuration is auditable rather than taken on faith. Requests go out live with a 90 second timeout and 5 attempts per page, paced so no provider is rate limited by test pressure. A miss is attributable to the target rather than to the harness.
A pass requires more than a successful status code. A 200 that returns a captcha interstitial or an empty JavaScript shell is a failure: the body must contain a marker, such as a product title or a listing address, that appears only on the real page. An error status, a timeout, or a body without the marker all count as failures.
The latency score is deliberately failure-aware. Per target it is the p75 of that provider’s successful attempts. A provider that returns nothing on a target inherits the p75 of the providers that did succeed there, and when nobody succeeds the target scores the 90 second timeout. A provider cannot look fast by failing quickly.
Our conflict of interest
String built this benchmark and String sells the product that ranks first in it. That is a real conflict, and the only useful answer to it is a test you can run without us. Everything needed to check the result is public, and the repository takes your own API keys.
Someone has already taken us up on it. An engineer at a competing provider showed that our adapter had chosen the wrong mode for their product, opened a pull request, and we merged it and reran the full benchmark. Their score went up by several points, and that higher number is the one published here. The offer stands for every provider on the board.
The results, in detail
Past runs
This page always carries the current run. Every run also gets a dated write-up covering what moved and why, and those are never edited after publication, so each one stays an accurate record of its own date.
Questions
What is the Web Data Frontier Benchmark?
An open-source test of how reliably web scraping providers return content from bot-protected pages. Each run sends 15 providers the same 99 real URLs, 5 attempts each, through adapters anyone can read. The harness, the target list, and the pass criteria are public, and the repo takes your own API keys.
What counts as a successful request?
A 2xx status is not enough. The response body has to contain a marker that appears only on the real page, such as a product title or a listing address. A captcha interstitial returning HTTP 200 counts as a failure, and so does an empty JavaScript shell.
How is the latency score calculated?
Per target, it is the p75 of that provider's 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 a provider for failing quickly.
String built this benchmark and ranks first in it. Why trust it?
You should not have to. Everything needed to check the result is public: the harness, the target list, the pass criteria, and every provider's adapter. Run it with your own keys. If a provider is configured badly, the adapter is one short file and a pull request fixes it, which has already happened once.
How often does it run?
The benchmark reruns on a regular cadence and this page always carries the current numbers. Each run also gets a dated write-up in the blog, listed below, and those are never edited after publication.