Firecrawl Pricing: Budget for Accepted Results
Firecrawl's basic scrape costs one credit per page. Your useful unit is the result your application can accept: a complete record, rendered content, or a table with the correct cell associations. Budgeting from successful HTTP responses alone misses that difference.
This guide answers the plan-price question first, then models a recurring URL list and explains a 200-credit controlled study. The study used free credits; it measured credit consumption, not cash expenditure. ScrapingAnt publishes this article and sells a competing retrieval API. There is no ScrapingAnt head-to-head test here.
Current Firecrawl prices
Checked October 2, 2026, in USD against Firecrawl's official pricing and its public pricing document:
| Plan | Monthly credits | Monthly bill | Annual invoice | Concurrency |
|---|---|---|---|---|
| Free | 1,000 | $0 | — | 2 |
| Hobby | 5,000 | $19 | $190/year | 5 |
| Standard | 100,000 | $99 | $990/year | 25 |
| Growth | 500,000 | $399 | $3,990/year | 50 |
| Scale | 1,000,000 | $749 | $7,190/year | 100 |
| Enterprise | Custom | Custom | Custom | Custom |
Annual invoices are paid yearly; they are not monthly subscription prices. Free credits refresh monthly. Paid top-ups come in $5 increments: Hobby gets 1,000 credits, Standard 2,000, Growth 2,500 and Scale 5,000 per increment. Check the billing spend cap before enabling automatic top-ups. Hobby, Standard and Growth plan credits do not roll over; Scale carries them for one month. Sources: official billing details.
Basic Scrape and Crawl cost one credit per page. Search is two credits per ten results; Interact is two per browser minute. JSON format on Scrape/Crawl adds four credits per page. A delivered error page can be charged even when a no-result scrape is uncharged. These are documented rates, not measurements from our basic-scrape study. Source: current credit table and failure policy.
Use the live pricing page for endpoint-specific limits and options before buying. This guide models basic retrieval; it does not price a mixed Agent, extraction, interaction or monitoring workload.
Model a recurring scrape bill
Keep three quantities separate:
- Documented prices: the plan and top-up rules above.
- Observed credits: the units consumed by recorded calls below.
- Modeled cash: a hypothetical subscription bill using stated workload assumptions.
For a known URL list, start with scheduled URLs × runs per month. Add billed retry attempts, then multiply by the credit cost of the selected operation. Count an accepted scheduled output once, even if it needed multiple attempts. If freshness matters, acceptance must also check the expected revision or maximum permissible age.
credits needed = (URLs × runs + billed retry attempts) × credits per attempt
modeled monthly bill = selected plan price + $5 × required top-up increments
cost per accepted output = modeled monthly bill ÷ accepted scheduled outputs
This simplified model starts a billing period with the plan allowance and no existing purchased credits. It excludes taxes, add-ons, other endpoints and your engineering/storage costs. A plan may also be required for concurrency or rate limits even when its credit allowance is underused.
The offline budget model and tests let you change URL count, cadence, retries, credits per attempt, accepted output and selected plan. Here is its tested default scenario, not an observed workload or invoice:
| Hypothetical workload | Standard, monthly billing |
|---|---|
| 1,000 URLs × 30 runs, no retries | 30,000 credits |
| Assumed accepted outputs | 27,000 |
| Modeled bill | $99 |
| Unused monthly plan allowance | 70,000 credits |
| Modeled cost per accepted output | About $0.00367 |
The assumed 27,000 outputs do not imply a measured 90% acceptance rate. Dividing $99 by the entire 100,000-credit allowance gives $0.00099 per credit at full utilization; it does not describe this partially used workload. At only 3,000 accepted one-credit outputs on Standard, the same $99 minimum means $0.033 each.
Compare plans with the same workload. For the 30,000-credit example, Hobby plus 25 top-ups models $144, while Standard models $99. At the Hobby allowance boundary, 5,000 credits model $19; 5,001 model $24 because top-ups are discrete. The scorer tests these boundaries, Free's allowance ceiling and zero accepted output, whose unit-cost ratio is undefined. These calculations do not establish which plan fits your concurrency needs.
What counts as an accepted result?
Define the application contract before measuring cost. A source-preserving retrieval and a usable business record can be different outcomes:
| Task | Acceptance check | Rejection example |
|---|---|---|
| Catalog ingestion | Required identities, numeric prices and currency | Correctly preserved “price unavailable” |
| Delayed page | Expected rendered text and loaded marker | HTTP 200 with initial placeholder |
| Labeled table data | Correct header/cell associations and required visibility | Flattened spans or a hidden row included |
| Fresh recurring document | Expected revision or acceptable age | Cached content older than your contract allows |
The last row is a recommended contract, not a measured freshness result. Our origin content stayed unchanged. Do not count delivered 404s, duplicates or incomplete records as accepted fresh documents simply because a request completed.
Observed credits per accepted output
On October 1, 2026, the study made 24 exploratory calls plus 176 preregistered calls against six owned synthetic fixtures and one missing path on a single GitHub Pages origin. Every billed call requested basic proxy, Markdown and HTML, without AI extraction or premium formats, and reported one credit. Total observed consumption was 200 credits. One extra connector-catalog rejection happened before transport and had a separately verified zero debit; it had no reported credit field and was not a returned fixture result.
The expansion comprised 112 fresh run slots across eight settings, 32 delayed-content pair calls, 16 permanent-404 diagnostic calls and 16 fresh/cache calls. The pilot stays separate from the balanced setting results. The public packet includes the dated design, sanitized attempt CSV, exact output strings, pinned fixture sources and offline acceptance checks.
Figure 1. Separate observed subsets, not a combined accuracy rate. Both attempts in each retry pair stay in the numerator. Source: chart data and renderer.
| Observed subset and contract | Credits | Accepted outputs | Credits per accepted output |
|---|---|---|---|
| Complete catalog, basic preservation | 14 | 14 | 1 |
| Delayed content, 2,500 ms wait | 14 | 14 | 1 |
| Corrective retry pairs, rendered content | 16 | 8 | 2 |
| Same-setting retry pairs, rendered content | 16 | 0 | Undefined |
These are different fixture contracts, not a provider-wide success rate. The missing-price catalog passed basic source-preservation checks in 14/14 balanced runs while supplying zero outputs meeting the separate two-numeric-prices requirement. Rejecting those records is an application decision; Firecrawl did not invent the missing price.
A billed HTTP 200 can be a placeholder
The delayed fixture changes its DOM after 1,500 ms. Default requests omitted waitFor. In eight same-setting pairs, the first and second calls both missed the rendered-content contract. In eight corrective pairs, failed first calls were followed by waitFor: 2500; all eight second calls passed. The corrective strategy consumed 16 credits for 8 accepted outputs, or 2 credits each, including the first failures.
Figure 2. Faithful offline rendering of saved outputs 56 and 57, with display styling added. Both reported target status 200 and one credit. Source: saved captures and rendering code. These are presentations of stored HTML, not screenshots taken during the API calls.
Text equivalent: the default output says Web Scraping is hard. The corrected output says I ❤️ ScrapingAnt (after 1500 ms) and loaded. Those strings belong to the synthetic fixture. They are not customer feedback or endorsements.
Set readiness to match your page and validate the result. The fixture does not establish a universal wait duration or retry probability. Repeating identical settings consumed 16 credits with zero accepted outputs; its ratio is undefined, not zero.
HTML and Markdown can serve different table contracts
Both balanced table modes preserved all 12 HTML table structures in 14/14 runs each, counting the nested table. Markdown retained tested ordinary values but had uneven pipe widths in the multirow-header, body-span and nested sections. It included the hidden AF-2 row in every balanced run, so each mode passed the strict visible-only Markdown contract in 0/14 runs.
Figure 3. Exact two-row-header extract from saved output 36: rendered HTML above, unchanged Markdown text below. Styling is added; cells and values are unchanged. Source: table render and stored outputs.
Text equivalent: the HTML header associates 2025 with Q1/Q2 and 2026 with Q1/Q2; North has values 10, 12, 14 and 16, and South has 7, 8, 9 and 11. The Markdown's first header row has three cells, its quarter row four, and its data rows five. Preserve HTML and reconstruct labels when your ingestion contract requires those associations.
Pipe Markdown has no native span syntax. These observations do not establish a Firecrawl-specific defect, and onlyMainContent is not a visible-only output guarantee. Define which format you need before counting an output as accepted.
Caching and error pages still need acceptance checks
Eight fresh/cache pairs produced eight reported cache hits with identical content; each cache repeat still consumed one credit. The source never changed, so this tests neither invalidation nor freshness after an edit. Sixteen expansion requests to the permanently missing path returned billed 404 pages. They provided no requested content; repeating a permanent 404 was a diagnostic exercise, not a recommended retry policy.
Reproduce the calculations without API credits
Download the pinned packet, open its directory and run the README commands. You need Python 3.10 or newer. Installing the pinned dependency needs package-download access; replay requires no credentials and makes no provider calls.
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -r requirements.txt
./run.sh
The stored replay output is:
Offline replay: 200 billed calls, 200 credits; 24 pilot + 176 preregistered; 201 connector attempts.
delayed-corrective-pair: 16 credits / 8 accepted = 2.0
delayed-same-pair: 16 credits / 0 accepted = undefined
Eight balanced settings: 14/14 basic preservation per setting; stricter contracts reported separately.
The script writes the recomputed CSV and JSON under expected_output/. If an input hash or count fails, stop and obtain the unchanged pinned packet; do not interpret a partial replay as the full study. To model your own hypothetical monthly workload:
python3 budget.py --plan Standard --urls 1000 --runs 30 --retry-attempts 0 --credits-per-attempt 1 --accepted 27000
Use your own observed accepted count when available. Do not substitute our fixture results for your production acceptance rate.
When to keep Firecrawl, and where ScrapingAnt fits
Firecrawl's Scrape documentation describes Markdown, HTML and structured output alongside rendering and caching controls. On the article fixture, main-content mode removed the tested cookie, aside and footer markers in 14/14 balanced runs, while whole-page mode retained them; both preserved the tested article content. That is a useful bounded strength for document ingestion.
Keep Firecrawl when its output meets your contract and its broader workflow fits your application. A low retrieval-only unit price does not replace required search, crawl orchestration, interaction or extraction. This page owns the budgeting decision; choosing an alternative also requires compatibility, freshness, migration and rollback tests that this study did not run.
For a known-URL retrieval task, you can evaluate ScrapingAnt against your own acceptance checks. For non-Google targets, its documented datacenter request costs are 1 credit without a browser and 10 credits with JavaScript rendering. Those are ScrapingAnt units, not interchangeable Firecrawl credits. See ScrapingAnt's credit costs. No matched ScrapingAnt costs or outputs were measured here, so there is no supported savings or superiority claim.
If that retrieval scope fits, create a ScrapingAnt account and validate a small compatible URL sample before committing a recurring workload. Keep Firecrawl when it already does the job; ScrapingAnt is not needed to replay this packet or calculate Firecrawl's bill.
For the broader planning question, see cost-efficient web scraping.
Study limitations and maintenance
All targets were synthetic, owned and on one origin. Repeated sequential requests shared one account and a short session; more repetitions do not add website diversity or establish statistical independence. The eight balanced settings passed their distinct basic checklists in 14/14 slots each; pooling them would create a misleading overall accuracy number.
There was no production anti-bot corpus, changed-origin freshness test, ScrapingAnt comparison, AI extraction test, throughput/SLA measurement or engine benchmark. Receipt, API HTTP-status and engine-timing fields were not surfaced. Target status and connector completion are distinct from useful output. Free-credit consumption is evidence about units, not an invoice. Prices and service behavior can change; recheck official billing inputs before making a purchase decision.
Offline examples tested on 2026-10-02 with Python 3.10.2 and lxml 6.1.1; stored retrievals were collected on 2026-10-01. Code and data: versioned public evidence packet.
AI agents assisted with drafting, export code, offline analysis, figures and automated editorial/factual review. ScrapingAnt is the publisher and Oleg Kulyk is the publication owner. No separate human review is claimed.