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

Which is better, String or Firecrawl?

Firecrawl is a crawler and String is an unblocker. On the open Web Data Frontier Benchmark of 100 real-world sites, 5 attempts each (September 16, 2026), String returned verified content on 97.0% of requests and Firecrawl on 80.2%. String was also faster: its failure-aware latency score of 7.06 seconds was the best of all 16 providers, and Firecrawl's 9.11 was second. Firecrawl returned nothing on 17 of the 100 sites, and String passed 14 of those 17 on every attempt. Pick Firecrawl for crawling cooperative sites to markdown. Pick String when specific hard pages have to come back every time.

• Choose String if specific hard pages have to come back every time. String returned 97.0% of requests and Firecrawl 80.2%, and String passed 40 of 40 social requests to Firecrawl's 10.
• Choose Firecrawl if you crawl cooperative sites to markdown, or need crawl, monitor, parse, or self-hosting.
• Do not switch if your list is docs, blogs, and news that Firecrawl already returns. Its latency score was second of 16 providers, behind only String.

TL;DR

• Success rate: String 97.0%, Firecrawl 80.2% (100 sites, 5 attempts each, September 2026)
• Speed: String 7.06s, Firecrawl 9.11s on the failure-aware latency score, first and second of 16.
• 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 27 sites the run does not attribute to a commercial anti-bot vendor, String returned content on 96.3% of requests and Firecrawl on 64.4%. That 31.9-point gap is the widest of any anti-bot category in the run.
• String bills only requests that return content. Firecrawl bills a blocked page that comes back as a 403 or 404 and not a scrape that returns nothing, so budget for the range.
• Firecrawl retired Smart Upgrade on August 29 and replaced automatic plan escalation with $5 pay-as-you-go increments. 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 100 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. The adapter has not changed since, and this page is built on the September 16, 2026 run, which used that same configuration.

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 17 shutouts below are not a flag we forgot to set. Every figure below comes from the September run's results JSON; pricing and billing terms were re-checked against both companies' live pages on October 27, 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.

The same request in Firecrawl and String

One job, done both ways: fetch a JavaScript-heavy product page and get its content back. Each request follows the vendor's own docs for that job, checked against those docs on October 15, 2026. Each one reads its key from an environment variable, such as $STRING_API_KEY.

curl -X POST https://api.firecrawl.dev/v2/scrape \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/product/123", "formats": ["markdown"], "maxAge": 0}'

curl https://request.usestring.ai/v1/fetch \
  -H "Authorization: Bearer $STRING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/product/123", "format": "markdown"}'

The two requests are the same shape: one POST, a bearer key, a URL, and a format. Firecrawl's scrape endpoint returns markdown by default and picks its own proxy, since the proxy parameter is deprecated in favor of auto. It also serves a cached copy when a recent one exists, so the example sends maxAge: 0, as the benchmark adapter does. String takes the key in a header, picks the fetch path and proxy class for each request, and bills the path it used. Add "executeJS": true if you want to force a browser. String returns a JSON envelope unless you ask for markdown. The code is the same length; the difference is what comes back from the hard pages above.

Success rate: String 97.0%, Firecrawl 80.2%

The benchmark sends 16 providers the same 100 URLs, 5 attempts each: 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.

Full table on the live leaderboard and in the September 2026 results post; the run date is September 16, 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: 17 sites returned nothing

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

The 17 sites where Firecrawl returned nothing on any attempt: Trustpilot, Home Depot, Saks Fifth Avenue, American Airlines, DigiKey, Instacart, Reddit, LinkedIn, Instagram, Facebook, TikTok, The New York Times, Pinterest, arXiv, Yelp, AutoTrader, and Temu. String passed the first 14 of those 5/5 and Yelp and AutoTrader 4/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 two: Coupang at 5/5 to our 4/5, and Idealista outright at 4/5 to our 0/5. Idealista is one of the two sites where String returned nothing, and it is the run's clearest point in Firecrawl's favor. Skyscanner, which Firecrawl won 5/5 to 0/5 in the August 11 run, went 5/5 for both in September.

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

Eight of the 100 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. For working code against both, see how to scrape X (Twitter) and how to scrape Reddit.

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

Group the 100 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 two of them they are level.

The last row is the one to read. The run does not attribute those 27 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: 31.9 points, against 14 points on Akamai and 6.7 on Cloudflare.

That changes what the headline 16.8-point gap is made of. Buying past a commercial WAF is close to a solved problem for both companies: the Fastly and Kasada rows are level, and Cloudflare and PerimeterX are within 6.7 points. 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 17 shutouts are visible within an hour of testing. The more expensive problem is the 8 sites where Firecrawl passed some attempts and failed others:

A scheduled job that clears Allegro 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: String is faster

On the benchmark's failure-aware latency score, String posted 7.06 seconds and Firecrawl 9.11, the two best numbers among all 16 providers. The score is a per-target p75 that charges a provider for the targets it fails, so neither number is bought with fast 403s. The lead also holds inside Firecrawl's coverage: on the 74 sites both returned on every attempt, the median site took String 2.65 seconds and Firecrawl 5.00. Firecrawl held the best score of the August 11 run, at 9.21 seconds to String's 9.98, so the order has changed once already and is worth re-checking on your own targets.

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. Pay-as-you-go buys a further $5 of credits whenever the balance runs out, in batches that scale with the plan, up to a monthly limit you set. It does not change the plan itself, and setting the limit 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 pay-as-you-go. The replacement leaves the customer on the smaller plan and sells credits in $5 increments at a higher marginal rate. On Standard, each increment 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: what a blocked page costs. Firecrawl's billing docs and pricing FAQ give the same answer, effective September 4, 2026. A scrape that returns no result costs nothing. A page that comes back with an error status such as 403 or 404 is still returned to you and costs 1 credit. So the price of a failure depends on how the site refuses: a 403 is billed, a request that never gets a page back is not. The benchmark does not record which of the two each failure was, so this page carries both ends as a range rather than picking the one that flatters us. At an 80.2% pass rate the two ends differ by roughly a quarter of the bill.

String's plan fee is paid in as usage credit. The first 20,000 standard fetches are free. Starter is $19 a month and includes $19 of usage; Growth is $99 and includes $99. Usage above that bills at the same rates. The per-request rate depends on what the page actually needed, and String publishes all four:

Unused credit rolls 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.25 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 above String's plain-fetch rate ($0.16 on Growth), spans its standard-browser and premium-request rates ($0.80 and $0.90), and sits below its browser-on-premium rate ($3.25). 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. At this volume String's standard and premium requests both sit under the $99 Growth fee, which covers them, so both come to $1.02; any of the fee you do not use rolls over. On the whole 100-site suite, Firecrawl Standard comes in under that in two of its four cells and over it in the other two, and every cell is cheaper than String's browser-on-premium path. Price is close to even, not where String wins. String wins on the 16.8 points of pages Firecrawl does not return at any price, and on 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, but test your own stores. Instacart and Home Depot returned nothing from Firecrawl, and String passed both 5/5. Firecrawl cleared Safeway, Kroger, Asda, and Lowe's on every attempt.
• 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: near tie. Both cleared Skyscanner, Expedia, Booking.com, Kayak, Delta, and Airbnb 5/5. American Airlines splits them: String 5/5, Firecrawl 0/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: Firecrawl, narrowly. Both cleared Zillow, Redfin, Realtor.com, Rightmove, Zoopla, and Apartments.com perfectly, and Idealista, the one real estate site that split them, went to Firecrawl. For the code, see how to scrape Zillow.
• 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. An agent opening a LinkedIn profile or an Instacart 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

What carries over. A /v2/scrape call becomes one POST to https://request.usestring.ai/v1/fetch. Keep the URL list and the code that reads markdown, and add "format": "markdown", because String returns a JSON envelope by default. Firecrawl's JSON format with a schema maps to String's jsonSchema extraction. The Python migration guide maps every Firecrawl parameter to String and shows a fallback that keeps Firecrawl as the primary.

What you rebuild. Crawl, batch scrape, monitor, change tracking, parse, and Interact sessions have no String equivalent. String's sitemap crawl lists every URL on a site, and each URL is then its own fetch. Most teams that switch keep Firecrawl for crawl and monitor jobs and point the failing fetches at String, and running both is a reasonable end state.

Integrations to reconnect. Firecrawl ships SDKs in nine languages, a CLI, a hosted MCP server, and integrations for n8n, Zapier, Make, LangChain, LlamaIndex, and many agent frameworks. String ships no language SDK, so an SDK call becomes one HTTP POST. Its hosted MCP server runs at mcp.usestring.ai, n8n calls String through the HTTP Request node, and Zapier, LangChain, and the Vercel AI SDK have setup guides in String's docs.

Test on your own failing URLs first. Take the URLs that fail on Firecrawl today, and any page where Firecrawl bills you for a 403 or 404, and run them through String. Compare pages returned and cost per usable page, then move only the targets that improve. Leave custom headers off for the test: String does not bill a blocked request unless that request sent custom headers. The first 20,000 String standard fetches are free with no card. If Firecrawl is one option among several, the Firecrawl alternatives comparison ranks the substitutes on the same benchmark.

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 (100 sites, September 2026), String passed 97.0% of requests and Firecrawl 80.2%.

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

String, by 16.8 points on the September 2026 benchmark. The gap is not spread evenly. Against Fastly and Kasada the two were level, and against Akamai it was String 98.0% to Firecrawl 84.0%. On the 27 targets the run does not attribute to a commercial anti-bot vendor, usually sites that defend themselves, String returned content on 96.3% of requests and Firecrawl on 64.4%. That 31.9-point gap is the widest of any anti-bot category in the run. Firecrawl returned nothing at all on 17 of the 100 sites, including LinkedIn, Instagram, Reddit, The New York Times, Instacart, and American Airlines; String passed all of those 5/5. Firecrawl won Idealista (4/5 to String's 0/5), a site String failed to clear.

Is Firecrawl faster than String?

Not in the September 2026 run. On the benchmark's failure-aware latency score, String posted 7.06 seconds, the best of all 16 providers, and Firecrawl 9.11, second. String was also faster on the 74 sites both returned in full.

Does Firecrawl charge for blocked requests?

Sometimes. Since September 4, 2026, Firecrawl's billing docs and pricing FAQ agree: a scrape that returns no result costs nothing, and a page that comes back with an error status such as 403 or 404 costs 1 credit. So a site that refuses with a 403 is billed, and a request that gets no page back is not. The tables above quote both ends as a range. 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.16 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 $3.25 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.03 annual and $0.99 to $1.23 monthly depending on whether failures burn a credit, against $1.02 for String Growth's standard and premium request paths, which both fit inside the $99 fee, and $3.25 for its browser-on-premium path. 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 September 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 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's latency score was second of 16 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, 100 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 September 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 its fix has been in every run since.