Web Data Frontier Benchmark: the August 2026 run
Each quarter, we publish the Web Data Frontier Benchmark, the test of an unblocker’s success rate for all enterprise-relevant industries and against all major anti-bot providers.
99 real-world targets, 15 providers, 5 attempts per page, 7,425 live billable requests, completed August 11, 2026. We ran our first run July 15th. The methodology and the argument for why this benchmark exists are in the original post. This one is the new numbers and what moved. We plan to add more sites and make changes as time goes on, but the main reason we keep updating this is that anti-bot challenges change over time. As companies update their anti-bot challenges, web scraping and data access companies need to update their strategies, making it crucial to have refreshed data on what’s working.
As we noted in July, let us know if you notice anything about your product that you think we should change. About a week after we posted the benchmark, a Firecrawl engineer gave us some pointers on running their harness, and then made a few changes to their internal anti-bot strategy to improve on some targets.
Our adapter forced their enhanced proxy mode, on the theory that every provider should run its strongest anti-bot setting. He showed that their default mode performs better, so we merged the fix. This run uses his configuration, and Firecrawl’s success rate rose 7.7 points on it. That is the mechanism working as designed, and the offer stands for every provider on the board.
Results
The full leaderboard, verbatim from the run’s output. Treat every number here as a snapshot of August 11, 2026 rather than a permanent ranking.
| 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 |
What changed since July
The target set grew from 90 sites to 99, so July and August are not a like-for-like comparison at the per-provider level. The latency definition is the same failure-aware, per-target p75 used in July. Every provider from the July field ran again, and none were added or dropped.
Ten providers moved by more than three points of success rate. Six went up and four went down.
| Provider | July 15 | August 11 | Change |
|---|---|---|---|
| Scrapingdog | 35.1% | 54.3% | +19.2 |
| Oxylabs | 68.9% | 76.8% | +7.9 |
| Firecrawl | 70.9% | 78.6% | +7.7 |
| Nimble | 59.3% | 66.3% | +7.0 |
| Zyte | 68.2% | 72.7% | +4.5 |
| ScrapingAnt | 35.1% | 30.7% | -4.4 |
| ScrapingBee | 33.3% | 29.7% | -3.6 |
| ScraperAPI | 69.3% | 64.2% | -5.1 |
| Browserbase | 50.0% | 42.2% | -7.8 |
| ZenRows | 44.2% | 34.3% | -9.9 |
The top five reordered below second place. String and Scrapfly held first and second. Bright Data fell from third to fifth, Context.dev rose from fourth to third, and Firecrawl rose from fifth to fourth.
String passed 97.0% of requests, 480 of 495, up from 95.8% in July, and its latency score improved from 11.07s to 9.98s. Firecrawl posted 9.21s, the fastest in this run, after improving from 14.70s in July.
Where providers specialise
An overall success rate hides the shape of a provider. Two products can land within a point of each other and fail on completely different parts of the web. The per-category cuts are where that shows up, and they are more useful than the leaderboard if you already know what you need to fetch.
Read the anti-bot cut first. These four vendors guard 63 of the 99 targets between them, so the numbers carry weight.
| Provider | DataDome (19) | Akamai (20) | Cloudflare (15) | PerimeterX (9) |
|---|---|---|---|---|
| String | 98% | 98% | 100% | 89% |
| Oxylabs | 77% | 67% | 77% | 98% |
| Firecrawl | 90% | 72% | 100% | 84% |
| Nimble | 72% | 44% | 35% | 82% |
| ScraperAPI | 55% | 85% | 60% | 58% |
The row worth pointing at is not ours. Oxylabs cleared 98% of PerimeterX targets and String cleared 89%, which makes PerimeterX the one column in this run where String is not first. It is also our weakest wall, and it is the system behind Skyscanner, one of the two sites we failed outright. If PerimeterX is most of your target list, Oxylabs handled it better than we did.
Nimble runs the opposite shape: 35% against Cloudflare and 82% against PerimeterX. ScraperAPI splits the same way in the other direction, 85% on Akamai and 55% on DataDome. Neither pattern is visible in an overall score.
Social platforms split the field in two
Eight of the 99 targets are social platforms, and the results there are close to binary. String, Context.dev, Bright Data, and Browserbase each returned content on every attempt or nearly so. Scrapfly reached 98%, Decodo and Nimble 95%. At the other end, Firecrawl reached 25% and ZenRows 0%.
That gap is not only a capability difference. Firecrawl returns HTTP 403 with a “this website is no longer supported” message on certain platforms, and one of its engineers has said the company blocks a number of the benchmark’s sites by policy. A blocklist is a product decision a vendor is entitled to make. For a buyer the effect is the same: no plan tier changes it.
Browserbase is the clearest specialist in the run. It returned content on every social attempt while scoring 11% against Cloudflare and 13% on travel targets. A real browser is the right tool for a narrow slice of the web and an expensive one everywhere else.
The run in detail
What we noticed
The number worth staring at is our own spread. String’s latency score improved this run, 11.07s to 9.98s, and on the 82 targets both String and Firecrawl cleared, String returned the page faster on 54 of them. The typical request is quick.
The tail is not. The median gap between our fastest and slowest attempt on the same URL is 5.7 seconds, against 1.8 for Firecrawl. Ten targets carry 44% of that spread on their own, and the worst of them swing 40 to 65 seconds between attempts. Something in our retry path fires on a minority of requests and is expensive when it does. A score built on a per-target p75 punishes exactly that shape, and it should. That fix is ours to land before the September run.
The other thing worth saying: this run is better because someone called us on the last one. Our July methodology picked a proxy mode for Firecrawl. One of their engineers opened a pull request showing their default mode does better, we merged it, and the whole benchmark reran on their configuration. Their number came in 7.7 points higher than July. An open harness only means something if a competitor can walk in and correct the record. This month one did.
Run it yourself
The harness, the 99target URLs, the pass criteria, and every provider’s adapter are public, and the repository takes your own API keys. A full run makes thousands of billable calls, so start with a subset. If your numbers differ from ours, open a pull request. Firecrawl did, and this run is the result.
The current leaderboard always lives at the benchmark page, which moves with every rerun. This post stays as published.
Cheers,
String team