String vs Firecrawl (2026): compared on 99 real-world sites

Firecrawl is a crawler and String is an unblocker. On the open Web Data Frontier Benchmark of 99 real-world sites, 5 attempts each (August 11, 2026), String returned verified content on 97.0% of requests and Firecrawl on 78.6%. Firecrawl was faster: its latency score of 9.21 seconds was the best of all 15 providers, ahead of String's 9.98. Firecrawl returned nothing on 16 of the 99 sites, and String passed 15 of those 16 on every attempt. Pick Firecrawl for crawling cooperative sites at speed. Pick String when specific hard pages have to come back every time.

TL;DR

• Success rate: String 97.0%, Firecrawl 78.6% (99 sites, 5 attempts each, August 2026)
• Speed: Firecrawl 9.21s, String 9.98s on the failure-aware latency score, first and second of 15. Firecrawl is faster.
• Social platforms: String passed 40/40 requests, Firecrawl 10/40 (X and YouTube only)
• Firecrawl blocks some sites by policy; its engineer confirmed 10 of the benchmark's targets
• On the 26 sites the run does not attribute to a commercial anti-bot vendor, String returned content on 96.2% of requests and Firecrawl on 59.2%. That 37-point gap is the widest of any anti-bot category in the run.
• String bills only requests that return content. Firecrawl's own pages do not agree on what a failure costs, so budget for the range and ask them which reading is right.
• Firecrawl retired Smart Upgrade on August 29 and replaced automatic plan escalation with $5 Auto-reload batches. On Standard, those reload credits cost 2.5 to 3 times the plan's included rate.
• Every number comes from a public harness you can re-run with your own API keys

How we tested, and our conflict of interest

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 99 target URLs, the pass criteria, and every provider's adapter are public, and the repo takes your own API keys.

Someone took us up on it. Our July run measured Firecrawl at 70.9% using a proxy mode our methodology chose for them. On July 24, a Firecrawl engineer opened a pull request showing their default mode performs better. We merged it, reran the full benchmark on August 11 with his configuration, and Firecrawl came in 7.7 points higher. That higher number is the one this page is built on.

An engineer will ask what configuration Firecrawl got, so here it is. The Firecrawl adapter posts to /v2/scrape with formats: ["rawHtml"] and maxAge: 0, and it sets no proxy parameter at all. Firecrawl's own documentation says that is the recommended setup: the proxy parameter is deprecated, the default is auto, and auto tries a basic proxy first and then retries with an enhanced proxy on failure, at no extra credit cost. So Firecrawl ran on its own recommended default, with escalation to enhanced proxies already switched on, and maxAge: 0 meant every attempt fetched a fresh page rather than a cached one. The 16 shutouts below are not a flag we forgot to set. Every figure below comes from the run's results JSON; pricing and billing terms were re-checked against both companies' live pages on August 29, 2026.

What each product is

Firecrawl is a full crawling platform: scrape, crawl, map, search, document parsing, browser interaction, and change monitoring behind one API, with Python and Node SDKs, a hosted MCP server, and an AGPL-3.0 core you can self-host. It defined the "URL in, markdown out" interface, and it is a genuinely good developer product.

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 that discovers every URL on a site, a /wss endpoint for a remote browser over CDP, and an MCP server at mcp.usestring.ai. There is no crawl endpoint that returns the content of every page on a site, no change monitoring, no document parsing, and no self-hosted option. Firecrawl has more product; String holds up on pages that fight back.

Success rate: String 97.0%, Firecrawl 78.6%

The benchmark sends 15 providers the same 99 URLs, 5 attempts each, every provider in its strongest mode: 7,425 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.

Full table on the live leaderboard and in the August 2026 results post; the run date is August 11, 2026 throughout.

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.

This benchmark measures retrieval on hard targets. It is not the axis Firecrawl publishes on. Their benchmarks hub carries a Developer Retrieval Benchmark, dated August 21, 2026, which runs 1,179 developer questions through 8 systems and scores whether the right repository, pull request, or docs page gets cited; the Firecrawl Developer Index leads it at 63.1% recall. Both can be true. Their benchmark asks how well a system finds and cites the right document. Ours asks whether a protected page comes back at all. Their stated method is the same one we used on them: "Every system gets the same inputs in the same order with default settings."

Where Firecrawl fails: 16 sites returned nothing

The 78.6% average hides where the failures sit. Per target, Firecrawl is perfect on most of the web and absent on a specific slice.

The 16 sites where Firecrawl returned nothing on any attempt: Safeway, American Airlines, AutoTrader, The New York Times, Ralph Lauren, LinkedIn, Instagram, Reddit, TikTok, Facebook, Instacart, Pinterest, Idealista, Trustpilot, arXiv, and Temu. String passed the first 15 of those 5/5. Temu shut out both providers.

Some of these failures are deliberate. In the same pull request that fixed our adapter, Firecrawl's engineer wrote: "We block 10 of the websites on the benchmark." Firecrawl returns HTTP 403 with "This website is no longer supported" on certain platforms, and their issue tracker shows self-hosted builds enforcing the same list. A blocklist is a product decision Firecrawl is entitled to make. For a buyer the effect is the same: no plan tier brings those pages back.

Firecrawl also won sites, and you should know which. It beat String on four: Allegro, Neiman Marcus, and Booking.com at 5/5 to our 4/5, and Skyscanner outright at 5/5 to our 0/5. Skyscanner sits behind PerimeterX, which defeated String on every attempt. That is the run's clearest point in Firecrawl's favor.

Social platforms: String 40/40, Firecrawl 10/40

Eight of the 99 targets are social platforms. String passed all 40 requests against them. Firecrawl passed 10 of 40: X and YouTube perfectly, and 0 of 5 on each of LinkedIn, Instagram, Reddit, TikTok, Facebook, and Pinterest. For social listening, creator analytics, or any product that reads public profiles, this is the whole evaluation. No pricing model fixes a 0% pass rate.

On X, where Firecrawl passed 5 of 5, its billing docs say requests to x.com are handled through the Grok API and cost 30 credits per request rather than 1: 1 base credit plus 29 for the Grok query.

The 37-point gap sits on sites with no commercial anti-bot vendor

Group the 99 targets by the anti-bot system in front of them and the difference stops being a single average. Against the named commercial vendors the two products are often close, and on some of them they are level.

The last row is the one to read. The run does not attribute those 26 targets to any commercial anti-bot product, usually because the site defends itself rather than buying one. It is the largest group in the benchmark, larger than Akamai or DataDome, and it is where the two products separate hardest: 37 points, against 26 points on Akamai and none at all on Cloudflare.

That changes what the headline 18-point gap is made of. Buying past a commercial WAF is a solved problem for both companies, and the Cloudflare row proves it. The pages that decide a purchase are the ones where a large site wrote its own detection, tuned it to its own traffic, and keeps changing it. Those are also the sites most worth scraping, which is not a coincidence.

Flaky targets corrupt datasets quietly

The 16 shutouts are visible within an hour of testing. The more expensive problem is the 12 sites where Firecrawl passed some attempts and failed others:

A scheduled job that clears Home Depot one attempt in five looks alive in monitoring while it starves the dataset: gaps in time series, prices that appear to move because a scrape silently missed. Retries paper over the problem and inflate the bill.

Speed: Firecrawl is faster

On the benchmark's failure-aware latency score, Firecrawl posted 9.21 seconds and String 9.98, the two best numbers among all 15 providers. The score is a per-target p75 that charges a provider for the targets it fails, so Firecrawl's lead is earned on the pages it can reach, not bought with fast 403s. On pages inside Firecrawl's coverage, Firecrawl is the faster product. A page that never arrives has no latency worth discussing, so which number matters depends on whether your targets sit inside that coverage.

Pricing: prepaid credits vs pay per success

Firecrawl sells prepaid monthly credits: Hobby $19 per month ($16 billed annually) for 5,000, Standard $99 ($83) for 100,000, Growth $399 ($333) for 500,000, Scale $749 ($599) for 1,000,000, and 1,000 free credits per month. A scrape costs 1 credit per page, and an enhanced-proxy request costs the same 1 credit, so a protected page costs what an easy page costs. Structured JSON output adds 4 credits per page. Plan credits do not roll over by default; annual Scale plans roll unused credits over one month and annual Enterprise plans two. Auto-reload buys a further $5 of credits whenever the balance runs out, in batches that scale with the plan, up to a monthly cap you set. It does not change the plan itself, and setting the cap to zero turns it off.

Firecrawl used to give customers more when they exceeded their plan credits. It introduced Smart Upgrade for June 1, 2026: overage spend moved the subscription up its credit ladder and paid the pro-rated difference. Less than three months later, Firecrawl retired Smart Upgrade and replaced it with Auto-reload. The replacement leaves the customer on the smaller plan and sells credits in $5 batches at a higher marginal rate. On Standard, each reload buys 2,000 credits, or $2.50 per 1,000, against $0.83 to $0.99 per 1,000 inside the plan. An overage credit now costs 2.5 to 3 times as much as an included credit. Firecrawl collects more per overage credit while the customer gets fewer credits per dollar.

Check one thing yourself before you budget, because Firecrawl's own pages read as opposites on what a failure costs. The billing docs say credits are charged whenever Firecrawl's infrastructure processes a request, "even if the target site returns an HTTP error status code such as 403 Forbidden or 404 Not Found". The same page puts the usual charge for a failed scrape at zero credits, and the pricing FAQ answers "Do you charge for failed requests?" with "No, we only charge for successful requests." We could not settle it from what Firecrawl publishes, so this page carries both readings as a range rather than picking the one that flatters us. At a 78.6% pass rate the two differ by roughly a quarter of the bill, which is worth an email to their team before you commit.

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, and String publishes all four:

Credits roll over on every plan, and a blocked request is never billed.

Comparing the two means converting Firecrawl's bundles into a price per 1,000 pages, which only works if you consume the whole allowance:

At the entry tier the gap is wide: Firecrawl Hobby is $3.20 to $3.80 per 1,000 pages against $0.30 per 1,000 on String Starter for a request-based fetch on a standard proxy. On Standard and above, Firecrawl's flat rate ($0.60 to $0.99) sits between String's plain-fetch rate ($0.20 on Growth) and String's premium and browser paths ($1.00 to $4.00). A page String clears on a plain fetch is cheaper on String. A page String has to render in a browser on a premium proxy is cheaper on Firecrawl Scale. Hard targets are the ones that need premium paths, so on exactly the pages this benchmark measures, Firecrawl's per-page rate is often the lower one when the page comes back.

The fairer unit is cost per 1,000 usable pages, which folds in the benchmark pass rate. At 100,000 requests a month:

Read that table honestly. On the whole 99-site suite, Firecrawl Standard comes in under String's plain-fetch path in three of those four cells and a shade over it in the fourth, and it is cheaper than String's premium paths in all of them. Price is not where String wins. The 18 points of pages Firecrawl does not return at any price is, along with a billing rule that is written down rather than inferred: String never bills a blocked request, so testing your own hard targets cannot charge you for pages you never received.

Which to pick, by job

• Grocery and home-improvement retail: String. Safeway and Instacart returned nothing from Firecrawl; Home Depot passed 1/5, Lowe's 2/5. String passed all four 5/5.
• Social and creator data: String. Firecrawl passed 10 of 40 social requests, and part of that gap is deliberate policy.
• News: either, with one exception. Firecrawl cleared The Wall Street Journal, Bloomberg, Reuters, Barron's, and MarketWatch perfectly. The New York Times returned nothing on 5 attempts. If NYT is on your list, that decides it.
• Travel: run your own list. Firecrawl took Skyscanner 5/5 where String took 0/5, and edged Booking.com. String took American Airlines 5/5 where Firecrawl took 0/5, and Expedia 5/5 to 3/5.
• Ticketing: tie. Ticketmaster, SeatGeek, StubHub, and AXS all passed 5/5 for both. Our July draft recommended String here; the rerun deleted that argument, so we deleted the recommendation.
• Real estate: near tie. Both cleared Zillow, Redfin, Rightmove, Zoopla, and Apartments.com perfectly. Firecrawl's soft spots were Idealista (0/5) and Realtor.com (3/5).
• RAG over docs and blogs: Firecrawl. Crawling a whole domain to content in one call, plus monitoring and document parsing, is a surface String does not replicate, and cooperative pages need no unblocker. String maps the same sites through its sitemap crawl, but fetching each URL is a separate call. One asterisk from this run: arXiv failed all 5 Firecrawl attempts.
• Agent web access: depends on the target list. Both ship MCP servers. An agent reading documentation is well served by Firecrawl, faster. An agent opening a LinkedIn profile or a Safeway listing needs String.
• Self-hosted or air-gapped: Firecrawl. It is the only one of the two you can run on your own hardware. One caveat matters more than the rest, and it comes from Firecrawl's own self-hosting guide: "Fire-engine or its advanced anti-bot behavior ... is not included" in the default stack. The self-hosted build does not carry the capability this benchmark measures; their open source versus cloud page sets out the rest of the difference. Two more from their tracker: self-hosted builds enforce the hosted blocklist (#1485), and self-hosted anti-bot performance has open issues (#495, #1363).

Switching from Firecrawl to String

There is no migration project. If you call /v2/scrape with a URL and read markdown out, the String equivalent is a POST to https://request.usestring.ai/v1/fetch with {"url": "..."}, and markdown comes back by default. Most teams that switch keep Firecrawl for crawl, map, and monitor jobs and point the failing fetches at String; running both is a reasonable end state. The first 5,000 String requests are free, which covers testing your own list of the pages that currently fail. If you are weighing Firecrawl against the rest of the market rather than against String alone, the Firecrawl alternatives comparison ranks seven tools on the same run.

FAQ

String vs Firecrawl: what is the actual difference?

Firecrawl is a crawler and String is an unblocker. Firecrawl crawls a whole domain to content, monitors pages for changes, and parses documents, with an open-source core you can self-host. String fetches single URLs that have anti-bot protection and bills only when content comes back. Both products map sites and both run a search endpoint. On the open Web Data Frontier Benchmark (99 sites, August 2026), String passed 97.0% of requests and Firecrawl 78.6%.

Which is better for scraping sites with anti-bot protection?

String, by 18 points on the August 2026 benchmark. The gap is not spread evenly. Against Cloudflare both returned content on 100% of requests, and against Akamai it was String 98.0% to Firecrawl 72.0%. On the 26 targets the run does not attribute to a commercial anti-bot vendor, usually sites that defend themselves, String returned content on 96.2% of requests and Firecrawl on 59.2%. That 37-point gap is the widest of any anti-bot category in the run. Firecrawl returned nothing at all on 16 of the 99 sites, including LinkedIn, Instagram, Reddit, The New York Times, Safeway, and American Airlines; String passed all of those 5/5. Firecrawl won Skyscanner (5/5 to String's 0/5), the one wall String failed to clear.

Is Firecrawl faster than String?

Yes. On the benchmark's failure-aware latency score, Firecrawl posted 9.21 seconds, the best of all 15 providers, ahead of String's 9.98. The score is a per-target p75 that charges a provider for the targets it fails, so the lead is real. Firecrawl is the faster product on pages it can reach; String's success rate is 18 points higher.

Does Firecrawl charge for blocked requests?

Firecrawl's own pages disagree, so check it before you budget. Its billing docs say credits are charged whenever its infrastructure processes a request, "even if the target site returns an HTTP error status code such as 403 Forbidden or 404 Not Found". The same page puts the usual charge for a failed scrape at zero credits, and the pricing FAQ says "No, we only charge for successful requests." We could not resolve that from what Firecrawl publishes, so the tables above quote both readings. String bills only requests that return verified content, so a block costs nothing either way.

Is String cheaper than Firecrawl?

On pages that clear on a plain fetch, yes, at every Firecrawl tier: String Growth's $0.20 per 1,000 is below Firecrawl's cheapest rate of $0.60. On pages that need a browser on a premium proxy, no: String's $4.00 path is above Firecrawl Scale's $0.60 to $0.75. Per usable page at 100,000 requests a month, Firecrawl Standard runs $0.83 to $1.06 annual and $0.99 to $1.26 monthly depending on whether failures burn a credit, against $1.23 for String Growth's plain-fetch path, and Firecrawl is cheaper than String's premium paths. Firecrawl's plan credits do not roll over below annual Scale; String rolls credits over and never bills a blocked request.

Can Firecrawl scrape LinkedIn, Instagram, or TikTok?

Not in the August 2026 benchmark. Across 8 social platforms, Firecrawl passed 10 of 40 requests, all on X and YouTube. LinkedIn, Instagram, Reddit, TikTok, Facebook, and Pinterest each failed all 5 attempts, and Firecrawl's engineer has stated the company blocks some benchmark sites by policy. String passed 40 of 40.

When should I stay on Firecrawl?

When you need a crawler rather than a fetcher, when your targets sit inside Firecrawl's coverage and speed or a flat per-page price matters, or when you need self-hosting. Crawling a domain to content, change monitoring, and document parsing have no String equivalent. Firecrawl posted the fastest latency score of all 15 benchmarked providers, and its AGPL core runs on your own hardware, though its self-hosting guide says the advanced anti-bot engine is not included in that stack. Mapping and search are not differentiators; String ships both.

How can I verify these numbers?

Run the benchmark. The harness, 99 target URLs, pass criteria, and per-provider adapters are public at github.com/usestring/web-data-frontier-benchmark, and it takes your own API keys. The live leaderboard and the August 2026 results post carry the same figures, and the raw results JSON is in the repo. A full run makes thousands of billable calls, so start with a subset. If your numbers differ, open a pull request; Firecrawl did, and this page is built on the rerun that followed.