Web Data Frontier Benchmark: the August 2026 run

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.

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.

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.

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

On our own spread, we noticed that latency moved significantly. String’s score improved this run from 11.07s to 9.98s average. On the 82 targets both String and Firecrawl cleared, String returned the page faster on the vast majority (54) of them. The typical request is quick.

The spread is significant though. The median gap between our fastest and slowest attempt on the same URL is 5.7 seconds. Ten targets carry 44% of that spread on their own. We’re working on our retry path to ensure that on the minority of requests where it fires and is expensive in shape, we can close this gap. That’s one of the reasons we built our latency score on a per-target p75, to punish this exact problem. Going to land this fix before the next run.

As mentioned earlier, our run is better because of external input. Thanks to a Firecrawl engineer showing us that their default mode performs better than the specific proxy mode we ran. Their pull request brought their number up 7.7 points higher than July. That’s why we have the open harness!

Every site, one by one

The charts above summarise the run. This is the run itself: all 99 targets, grouped into the 13 verticals they were drawn from, easiest first inside each one. A cell counts the attempts that returned the real page, out of 5.

String returns every attempt on 92 of the 99 sites. It is beaten on 4: skyscanner.net, neimanmarcus.com, allegro.pl, booking.com. Latency is left out of the cells, because a provider that never returned a target has no measured latency to report there.

Run it yourself

The harness, the 99 target 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