Firecrawl Pricing (2026): What a Credit Actually Buys

Direct answer

Firecrawl bills one credit per page for scrape, crawl and map — but not for everything. Search costs 2 credits per 10 results, interact costs 2 credits per browser minute, and monitor costs 1 credit per page per check, so a monitored page is not a one-off cost but a recurring one. Plans, read on firecrawl.dev/pricing Aug 2, 2026 and billed yearly: Free $0 (1,000 credits a month, no card, 2 concurrent requests), Hobby $16/month (5,000 pages, 5 concurrent), Standard $83/month (100,000 pages, 50 concurrent), Growth $333/month (500,000 pages, 100 concurrent) and Scale $599/month (1,000,000 credits, 150 concurrent), with a custom Enterprise tier adding zero-data retention and SSO. Those are the yearly-billed rates; monthly billing costs more, and Firecrawl does not publish the monthly figure in a form we could read.

Last verified

Aug 2, 2026

How we know

Desk-verified against primary sources

Sources

3 linked

Evidence used

• Every plan price, credit allowance and concurrency limit was read in the server-rendered HTML of firecrawl.dev/pricing on Aug 2, 2026 — unusually for this category, the whole table is fetchable rather than drawn client-side.
• The per-endpoint credit costs (scrape 1/page, crawl 1/page, map 1/page, search 2 per 10 results, interact 2 per browser minute, monitor 1 per page per check, Agent in preview with 5 free daily runs) come from the API Credits table on that same page, same date.
• The monthly-billing prices are deliberately absent below. The pricing page defaults to yearly billing and states only a savings figure per tier; the monthly numbers are not in the fetchable HTML, and the two integers that look like them turn out to be a React reference and a CSS class name. We publish the gap rather than a derived figure.
• This is a documentation explainer, not a ToolProven bench test. We have not run Firecrawl on our standard task and publish no measured throughput, latency or success-rate figure for it.

How we checked this

• Prices and credit rates were read directly from the vendor's own pricing page on Aug 2, 2026 and are reproduced as published. Scraping vendors reprice often — check the live page before committing budget.
• Cost-per-1,000-pages figures below are arithmetic on the published yearly-billed prices and credit allowances, not metered runs. They assume the 1-credit-per-page endpoints; search, interact and monitor change the maths, which is the point of the credit section.
• Where a figure is not published — the monthly-billing prices, the Agent endpoint's dynamic rate — we say so instead of estimating.

One credit is not one page — the table that decides your bill

Scrape, crawl and map each cost 1 credit per page, which is the rate everyone quotes. Search costs 2 credits per 10 results, interact costs 2 credits per browser minute, and monitor costs 1 credit per page per check — so the three endpoints most likely to run continuously are the three that do not bill per page.

This is the whole article in one table, and it is the part roundups skip because the plan prices are easier to copy. Firecrawl publishes an API Credits table alongside its tiers, and the rates are not uniform. If your workload is a one-off crawl of a documentation site, the 1-credit-per-page figure is the right mental model and your bill is predictable. If your workload is an agent that searches, clicks through pages, or watches a set of URLs for changes, it is not.

The monitor rate is the one that changes budgets most, because it is the only line that bills on a clock rather than on an action. One credit per page per check means a hundred pages checked hourly is 2,400 credits a day — roughly half the Hobby plan's entire monthly allowance, spent in a day, on a hundred pages. Nothing about that is hidden; it is simply a different unit from the one the headline invites you to use.

Interact is the other one to model before you commit. At 2 credits per browser minute it bills for time rather than for pages, which is the correct shape for a browser-automation endpoint and the wrong shape for a spreadsheet that assumes pages. And the Agent endpoint is in preview with 5 free daily runs and dynamic pricing — no fixed rate is published, so we do not print one.

What a thousand pages costs, by plan

On the 1-credit-per-page endpoints, Standard is the cheapest rate at $0.83 per 1,000 pages and Hobby the most expensive at $3.20 — but only if you use the allowance, because unused credits are the real cost on the smaller tiers.

Converting each tier to one unit is the only way to compare them, and it produces an ordering that is not the plan order. Standard at $83 for 100,000 pages works out to $0.83 per thousand; Growth at $333 for 500,000 is $0.67; Scale at $599 for a million is $0.60. Hobby, at $16 for 5,000, is $3.20 — nearly four times Standard's rate.

That does not make Hobby bad, and this is where per-unit tables mislead if you stop reading. A rate only matters if you consume the allowance. Someone scraping 4,000 pages a month pays $16 on Hobby and would pay $83 on Standard for the same work, so Hobby is five times cheaper in practice while being four times more expensive per page. The break-even against Standard sits around 26,000 pages a month — below that Hobby wins on total cost, above it the rate takes over.

The Free tier deserves its own line because it is a genuine evaluation budget rather than a demo: 1,000 credits a month, no card, 2 concurrent requests. That is enough to run a real crawl of a small site and watch how your own workload consumes credits before any money moves — which, given the endpoint table above, is the only reliable way to size a plan.

What Firecrawl does not publish, and why we are not guessing

The monthly-billing prices are not in the page's fetchable HTML — only the yearly rates and a savings figure per tier. The Agent endpoint's rate is dynamic with no published number. We print neither.

The pricing page defaults to yearly billing and shows each tier's saving against monthly rather than the monthly price itself. It would be easy to derive one — subtract the saving, divide by twelve — and easy to be wrong, because the savings are rounded. We looked for the real figures in the page payload and found two integers that fit the shape, then checked their context: both turned out to be a React internal reference and a CSS class name rather than prices. So the monthly numbers stay unpublished here, and any article quoting them without saying where it read them is worth a second look.

This matters more than it sounds for a scraping tool, because the audience is technical and will check. What Firecrawl does publish is more than most of its category manages: the whole plan table and the whole credit table are server-rendered and readable by a fetcher. Its competitors mostly are not — Apify's pricing is readable, but several vendors in this space draw their plan cards in the browser and hand a crawler nothing.

Who Firecrawl fits, and who should look elsewhere

It fits developers who want clean markdown out of a URL with minimal setup and are billing per page. It fits worse if your workload is dominated by monitoring or browser interaction, where the meter changes unit, or if you need a marketplace of prebuilt scrapers.

The pitch is narrow on purpose: give it a URL, get back model-ready markdown, with the crawling, rendering and cleanup handled. For an agent that needs to read a page, that is most of the job, and the credit maths is trivial to model at 1 per page. It is a different product from Apify, which is a marketplace of thousands of prebuilt Actors metered in compute units, and from Context.dev, which sells a flat per-credit rate with proxies bundled.

The honest caveat is the one we apply to every tool we have not run: nothing on this page is a measurement. We publish no throughput, latency or success-rate figure for Firecrawl because we have not put it through our standard task, and the vendor's own testimonials quoting a 50× speed comparison are marketing rather than a benchmark we can verify. What we can verify is the meter, and the meter is what decides the bill.

Related ToolProven pages