Firecrawl vs Spider 2026: crawl speed, MCP and pricing

Firecrawl is for teams that want a polished TypeScript product with a big community, a schema-driven extract endpoint, and a monthly credit bundle they can put on a card and forget. Spider is a research lab for web data quality. The product is a Rust crawler exposed as an API, and the thing we measure ourselves on is whether the page that comes back is complete and correct, at any volume, on any site. Speed and cost are the evidence for that, and they are what this post spends most of its words on.

The verdict, before the detail. If you fetch under 100,000 pages a month, rarely touch protected sites, and value documentation and ecosystem over raw throughput, Firecrawl is a fine pick and you will not regret it. If your workload is large, spiky, or full of sites that fight back, Spider returns more of the pages you asked for, faster, for a bill that tracks what you used instead of a bundle you have to size in advance. The rest of this page shows the numbers behind both halves of that sentence, with the caveat that the benchmark figures are our own measurements and not independently verified. You can also compare every vendor we track on the compare page.

Side by side

Firecrawl pricing in 2026

Firecrawl sells credits by the month. One credit is one scraped or crawled page, and add-ons stack on top of that. Here is the lineup as of September 2026, from the Firecrawl pricing page. The page only rendered the “billed yearly” toggle when we read it, so the month-to-month column is derived from the yearly price plus the printed “Save $X” figure, and it matches what two pricing trackers list. Firecrawl’s billing docs confirm both billing periods exist.

The rules around the table matter as much as the table. Plan credits do not roll over by default. Use 60,000 of Standard’s 100,000 and the other 40,000 are gone at the end of the period. Annual Scale plans keep unused credits for one month and annual Enterprise plans for two. Overage auto-reloads in $5 batches at the plan’s rate, so a Hobby overage credit costs $0.005 and a Scale overage credit $0.001. Rate limits scale with the plan too: 10, 100, 500, 5,000 and 10,000 scrape requests per minute from Free to Scale, and 2, 20, 100, 1,000 and 2,000 crawl requests per minute.

Credit costs per operation, from the billing docs: scrape and crawl are 1 credit per page, map is 1 per call, search is 2 credits per 10 results. JSON extraction adds 4 credits per page, so a structured page costs 5. PDF parsing adds 1 credit per PDF page. Stealth mode, which Firecrawl calls enhanced proxy, now costs the same 1 credit as a basic request, which is a change from the 5 credits older third-party posts still quote. Firecrawl’s extract endpoint bills by tokens at 15 tokens per credit, and its agent runs are dynamic. Most agent runs “consume a few hundred credits” in Firecrawl’s own words.

A worked example. 10,000 basic pages a month does not fit Hobby’s 5,000 credits, so you either step up to Standard at $83 or run Hobby plus five $5 overage packs for $41. 100,000 pages is Standard at $83 on yearly billing. 1,000,000 pages is Scale at $599, because Growth plus 500,000 overage credits comes to $1,333.

Spider pricing, same volumes

Spider bills two meters and nothing else: $1 per GB of content transferred and $0.0001 per CPU minute of processing. JavaScript rendering rolls into compute. Standard proxy rotation is included. Failed requests cost nothing. Credits never expire, and you can start with $1.

For 100,000 pages in smart mode that comes to about $8 to $15. 10,000 pages in HTTP mode is about $0.80 to $1.00. A million pages in chrome mode with markdown and metadata lands around $80 to $160. The pricing guide shows how those bands are built and what each request mode costs. If you would rather have a fixed monthly bill, the Unlimited plan sells concurrency instead of pages, from $40 a month for two units, with a smaller flat-rate proxy pool than pay as you go.

Put the two side by side at 100,000 pages and Firecrawl is $83 to $99 against Spider’s $8 to $15. At 10,000 pages the gap is larger in ratio terms because Firecrawl’s bundles do not shrink below a plan floor while Spider’s bill does. At a million pages, $599 to $749 against $80 to $160. Every account also gets 10,000 requests per minute by default, which is the kind of ceiling Firecrawl only reaches on Scale.

What both did on the same 1,000 URLs

We ran both APIs over a 1,000-URL corpus in February 2026, split across static pages, JavaScript-heavy apps and sites behind common bot-protection services. The method, URL categories and per-tier results are in the benchmark post. These are our own numbers, not independently verified, and you should treat them as a starting point for your own run rather than a ruling.

The 4.6 point gap in success rate is 46 pages per 1,000. In a retrieval pipeline each of those is a document that never reaches the vector store, and the user who asks about it gets a confident wrong answer. That is why we lead with completeness rather than speed. The throughput gap is widest on static pages, where smart mode fetches over plain HTTP and only opens a browser when the page needs one.

One third-party reading, for balance. Scrapeway’s August 2026 run listed Firecrawl at a 64% success rate, 4.7 seconds average response and $5.18 per 1,000 requests, fourth of nine APIs tested. Their corpus and ours are different, so do not stack the two numbers. We include it because it is the only independent measurement we found.

Which web crawl MCP is faster

An MCP server is a thin protocol layer over the crawler underneath it, so MCP crawl speed is mostly the speed of the engine it calls. Both Spider and Firecrawl ship MCP servers that expose their own crawl and scrape endpoints, which means the throughput numbers above carry over: 74 pages a second against 16 on the mixed corpus.

Two properties matter more than raw throughput once an agent is driving. The first is how long the tool call blocks, because an MCP call holds the agent’s turn until it returns. The second is whether the crawl returns synchronously. Spider’s MCP crawl returns results directly or streams them as JSONL. Firecrawl’s crawl is async, so the agent polls until the job finishes, and that wall-clock time never shows up in a pages-per-second figure. Firecrawl’s server does cover more ground, with scrape, crawl, map, search, agent and browser tools, and it is MIT licensed even though the core is not. Spider’s server covers the core and AI endpoints; setup is on the MCP page.

The AGPL question

This one gets skipped during evaluations and then surfaces in legal review.

Firecrawl’s AGPL-3.0 means that if you modify the source and serve it over a network, which is what building a SaaS on it amounts to, you must release those modifications under the AGPL. For companies building proprietary products on top of the scraping layer, that usually makes the cloud API the only practical path. The self-hosted build also ships without the hosted anti-bot engine, screenshots and actions, the agent, and the browser tools, per Firecrawl’s own self-host guide.

Spider’s crawler is MIT. Modify it, embed it, sell it, no source obligation. If you only consume either cloud API this distinction does not touch you. If self-hosting or building on the open source code is on the roadmap, bring legal in early.

Where Firecrawl wins

Developer polish is real. The docs are thorough, the API is tidy, the TypeScript SDK has good types, and the crawl, poll, fetch results flow is documented end to end.

Community gravity. The repo had 175,600 stars when we checked in September 2026. That is more blog posts, more Stack Overflow answers, and more engineers on your team who have already used it. When a non-technical stakeholder asks “is this thing safe to bet on”, stars answer the question for you.

SDK breadth. Nine official SDKs, including Java, Elixir, Ruby, .NET and PHP. Spider covers Python, JavaScript, Rust, Go and a CLI, so if your stack is Elixir or .NET, Firecrawl has you covered and we do not.

The map endpoint discovers a site’s URLs for one credit per call without fetching content, which is a cheap way to scope a crawl before paying for it. And schema-driven extract, with Zod or JSON Schema, gives you a typed, repeatable output when you know the shape you want in advance.

Where Spider wins

Completeness on hard sites. 99.9% against 95.3% on the same corpus, with the caveat above. The gap opens on sites behind common bot-protection services, which is where most production targets live in 2026.

Throughput. 4.6 times the corpus average, and the static-page gap is wider still, because smart mode does not open a browser it does not need.

Billing that tracks usage. No bundle to size, no credits vanishing at month end, no overage packs. Failed requests cost $0, which is the line most people miss: a page that returns an error is a page you did not pay for.

MIT licensing on the crawler, and a live browser. Spider Browser gives you a WebSocket session on a real page with extract, act, observe and agent methods that work on the DOM after clicks and scripts have run. The old sample in this post had a placeholder URL; here is the shape of it:

import { SpiderBrowser } from "spider-browser";

const spider = new SpiderBrowser({
  apiKey: process.env.SPIDER_API_KEY,
});

await spider.init();
await spider.page.goto("https://spider.cloud/pricing/");
await spider.page.waitForSelector("table");

const pricing = await spider.page.extract(
  "List every plan name with its price and what it includes"
);
console.log(pricing);
await spider.close();

Format flexibility from one parameter. return_format gives you markdown, commonmark, plain text, XML, raw HTML or bytes from the same endpoint, and responses can come back as JSON, JSONL, CSV or XML.

Migration: the same crawl in both SDKs

Crawl a site, get markdown back, print the size of each page.

Spider

from spider import Spider
import os

client = Spider(api_key=os.getenv("SPIDER_API_KEY"))

pages = client.crawl_url(
    "https://spider.cloud/docs/",
    params={
        "limit": 10,
        "return_format": "markdown",
        "request": "smart",
    },
)

for page in pages:
    print(f"{page['url']}: {len(page.get('content', ''))} chars")

Firecrawl

from firecrawl import FirecrawlApp

app = FirecrawlApp(api_key="fc-YOUR_API_KEY")

result = app.crawl_url(
    "https://spider.cloud/docs/",
    params={
        "limit": 10,
        "scrapeOptions": {
            "formats": ["markdown"],
        },
    },
    poll_interval=2,
)

for page in result.get("data", []):
    print(f"{page['metadata']['url']}: {len(page.get('markdown', ''))} chars")

The two calls look alike. The difference is underneath: Firecrawl’s crawl is a job you poll or subscribe to with a webhook, while Spider’s /crawl returns the pages in the response or streams them. The parameters, request modes and streaming options are on the crawl endpoint docs.

When to pick which

Pick Firecrawl when your volume is moderate, your targets are mostly cooperative, your team already lives in its ecosystem, or you want schema-driven extraction with deterministic output and a monthly bill that never surprises you. Pick it too if your language is one Spider does not cover.

Pick Spider when completeness on protected sites is the requirement, when throughput at scale is the requirement, when the bill needs to follow usage instead of a plan floor, or when MIT licensing on the crawler matters for what you are building. The same choice comes up with the other tools in this series; see Spider vs Crawl4AI for the self-hosted case and Spider vs Jina Reader for the single-URL case, or the wider best Firecrawl alternatives roundup.

Both are production tools with active teams behind them. The cheapest way to settle it for your own targets is to run the same URL through the playground and look at what comes back.