Firecrawl Review 2026: API Features, Pricing and What to Actually Buy
Try Gologin for free
TL;DR + Product Breakdown Table
Firecrawl is a web data API with five core endpoints (Scrape, Search, Crawl, Map, and Interact) behind one API key and one credit pool. Each endpoint meters usage differently: per page, per call, per 10 search results, or per browser minute.
In my tests (October 2026, real billable credits), Scrape returned accurate Markdown (all 44 control strings survived conversion), and its default auto proxy mode got through 40 of 40 requests to Walmart (Akamai, HUMAN) and Leboncoin (DataDome) at 1 credit each.
Two things to know before you buy. First, Firecrawl serves cached pages up to two days old by default; set maxAge to 0 to force a fresh scrape. Second, its product-data extraction is inconsistent: the product format returned nothing on Walmart, and the json format returned a wrong price twice. Interact profiles keep logins and cookies but get a new IP address in every session.
| Product | Billing | Cost (Hobby / Standard) | Test result |
|---|---|---|---|
| Scrape | 1 credit per page and 5 credits with json format for product data |
$3.80 / $0.99 per 1,000 pages ($19.00 / $4.95 with json format) |
40/40 protected requests; all 44 control strings preserved in Markdown |
| Crawl | 1 credit per returned page | $3.80 / $0.99 per 1,000 pages | Found all 84 sitemap pages in both runs (plus 3-4 pages outside the sitemap) |
| Map | 1 credit per call | $3.80 / $0.99 per 1,000 calls | Returned all pages in the site’s sitemap bar the starting URL. |
| Search | 2 credits per 10 results, plus 1 credit per scraped result | $7.60 / $1.98 per 1,000 queries (results only) | Official docs ranked 1st or 2nd in 5/5 queries |
| Interact | 2 credits per browser minute with code, 7 with an AI prompt (1-minute minimum) | $0.46 / $0.12 per hour with code; $1.60 / $0.42 with a prompt | Completed all tasks, both code-driven and AI-prompted. Interact also persists login and localStorage using a Firecrawl profile between sessions, but not IP address. |
What it is and who it’s for
Firecrawl is a web data API for searching, scraping, and interacting with the live web. You send it a URL or a query, and it returns clean Markdown, structured JSON, HTML, links, or screenshots.
Raw HTML often contains data, such as navs, CSS, images, footers, and ads, which wastes tokens and is of no use to LLMs. You’d typically need to clean that data first: an action that adds code, time, and costs to your pipeline. Firecrawl eliminates that extra step. You send it a query or URL, and it returns clean, AI-readable results in Markdown or structured JSON. In my tests, the Markdown was 58-99% smaller than the raw HTML (see Table 2).
Firecrawl also handles the hard stuff - JavaScript, proxies, smart waits, and whatever’s required for any given site - automatically, with zero configuration. Every endpoint (Search, Scrape, Interact, and the rest) uses one API key and is billed from the same credit pool, though they each use different metering units; I’ll discuss that in more detail in the pricing section of this review.
Firecrawl is also designed to find pages. Map lists every URL it finds, Crawl follows links recursively and scrapes each page it finds, and Search finds pages from a query and can return the full content of each result as Markdown. It’s also great for monitoring product data, even more so because you don’t need to write and maintain CSS selectors that can break as sites update layouts. Firecrawl handles all that with a model that extracts fields from a schema or plain-language prompt, and its product format retrieves standard product information without a model.
Who it’s for: teams building AI agents, RAG pipelines, and LLM tools that need readable page content; developers who want to discover and crawl whole sites without maintaining a crawler; and anyone monitoring product data who would rather describe fields in a schema or prompt than maintain CSS selectors.
Who it’s less suited to: workflows that must return to a site as the same logged-in user from the same IP address over days or weeks (see the Interact results), and teams that want raw proxies to plug into their own scrapers, since Firecrawl doesn’t sell standalone proxies.
If your results seem different, you should know that Firecrawl uses a few defaults you may need to configure to your needs. For example, all crawls follow robots.txt rules, and you can only ignore these rules in an Enterprise plan; Browser sessions last 10 minutes by default, though standalone sessions can be extended up to an hour. While these sessions can persist cookies and localStorage using a Firecrawl profile, the docs don’t say anything about whether a profile keeps the same IP address and browser fingerprints.
Testing Methodology
I ran a custom test suite for each core Firecrawl endpoint plus five cross-cutting tests that check its claims on accuracy, caching, proxies, structured data, and persistent profiles. Each target isolates one variable; here’s a breakdown of the tests and why I chose each target:
Raw HTML to Markdown accuracy: Firecrawl’s main value proposition is making web data easily accessible to AI agents. That means Firecrawl returns structured data, right off the bat. To verify that the returned content actually contains valuable data, I chose 4 targets with different layouts:
- Documentation (uv): a basic Python tool documentation website.
- Information hub (Wikipedia).
- Yahoo Finance articles: ad-heavy pages, with valuable content nested between ads and widgets.
- An open Shopify store (Allbirds product pages): how Firecrawl pulls product data.
For each page, I recorded exact strings from different positions in its visible content (44 in total across 15 pages), and each had to survive the conversion to count as a pass.
Caching: Firecrawl’s documentation says it can return cached copies of a page up to 2 days old, by default. I wanted to test what that looks like in practice: I requested 3 documentation pages, 3 Wikipedia pages, along with 2 pages from a news website that changes every few minutes (Hacker News newest-submissions list). This test ran 3 times per target and compared the default result with forced fresh scrapes.
Proxy: Firecrawl provides 3 proxy modes (basic, auto, and enhanced), but uses auto by default. For this case, I ran each mode against four Walmart product pages (behind Akamai and HUMAN) and three Leboncoin category pages (behind DataDome), 20 requests per target, and recorded success rates and the cost per request and per successful request.
Structured data: To test Firecrawl against a real-world use case (retrieving product data from e-commerce sites), I extracted valuable data fields from Allbirds product pages and Walmart using both Firecrawl’s LLM-based json format and its deterministic product format. I compared each result against data I recorded from each page’s visible content on test day, and I also ran the json extractions 4 times for a consistency check.
Persistent profiles: Earlier, I mentioned that Firecrawl persists cookies and localStorage, but I couldn’t find anything about IP addresses in the documentation. So, I thought it’d be a valuable test for real-world use cases that require profiles to originate from the same network. I logged in with a saved profile to a demo website (quotes.toscrape.com/login) that accepts any credentials and opened the same profile in 7 separate sessions over 12 hours, recording the IP address and browser fingerprint.
Each run used real billable credits I got from creating my own Firecrawl account and getting the 1,000 free credits the Free plan gives every month; I didn’t pay for extra credits. Scrape responses don’t show the credits billed in a header, so I read my account balance before and after every group run and calculated the difference. Crawl and Search jobs do report creditsUsed, and they match the balance change.
Product Lineup Breakdown: Which Product for Which Task
Firecrawl’s endpoints overlap: Crawl and Search both run Scrape under the hood, and Map and Crawl both discover URLs. So the useful question isn’t what each endpoint does, but which one to call for a given job. Here’s what each core product is designed for:
-
Search: It accepts a query and returns the title, description, and URLs for every result. Adding the scrapeOptions parameter can get you the full-page Markdown, HTML, links, or a screenshot of each result.
-
Scrape: the core endpoint, on top of which some other endpoints on this list run. Firecrawl Scrape takes a URL and returns clean Markdown or structured data for AI agents.
-
Monitor: essentially scheduled Scrape; I didn’t test this endpoint, and my thought process, besides the fact that it may require weeks to get accurate results, was that Monitor and Scrape would yield very similar outcomes.
-
Interact: this endpoint allows you to simulate browser actions and is particularly useful when you need to interact with a page, for example, entering credentials and logging in, to access its content.
-
Map: primarily discovers URLs from a website’s sitemap; you give it a URL or domain, and it returns the URLs it finds across the site.
-
Crawl: another endpoint that runs on Scrape. It accepts a URL, recursively discovers new URLs, and scrapes every subpage.
Here’s how I’d choose between them:
| Your task | Use | Why this one | Billing unit |
|---|---|---|---|
| Get one known page as Markdown or JSON | Scrape | Cheapest unit; every other endpoint adds discovery or browser time on top | Per page |
| Get many known URLs | Batch scrape | Same per-page price as Scrape, but one async job instead of many calls | Per page |
| List every URL on a site before deciding what to fetch | Map | 1 credit per call, no matter how many URLs it returns | Per call |
| Get the content of a whole site or section | Crawl | Discovers and scrapes in one job | Per returned page |
| Find pages you don’t have URLs for | Search | Ranked results; add scrapeOptions to get each page’s content in the same call | Per 10 results + per scraped result |
| Click, paginate, fill forms, or log in before reading | Interact | The only endpoint with a live browser you control | Per browser minute |
| Re-check the same pages on a schedule | Monitor | Scheduled Scrape with change tracking | Per page per check |
| Hand off a multi-step research task | Agent (preview) | Plans and browses on its own; hard to budget | 5 free runs/day, then dynamic |
Rules of thumb from my testing:
- Map, then Scrape when you need only part of a site. Discovery costs a single credit, and you pay only for the pages you fetch.
- Crawl when you need everything. It costs the same per page as Scrape, and it may pick up pages that aren’t in the sitemap (and bill for them).
- Plain Markdown or the
productformat first,jsonlast. Thejsonformat costs 5x more and was the least consistent output I measured. - Interact only when a page needs a login or clicks. It’s the only endpoint where cost depends on time rather than pages, so keep sessions short.
Individual Tests per Product
The combined results from my terminal log (completed October 21, 2026) show consistently high success rates across all five endpoints:
| Product | Success rate | Median latency | Billing unit |
|---|---|---|---|
| Scrape (default proxy) | 100% (40/40 requests to protected pages) | 1.3–8.2s per page | 1 credit per page; 5 with JSON |
| Crawl | 100% of sitemap pages found (2 runs) | 84–92s for about 88 pages | 1 credit per returned page |
| Map | 99% of sitemap pages listed (83/84) | 0.85s | 1 credit per call |
| Search | 100% (official docs ranked 1st or 2nd in 5/5 queries) | 1.2s; 2.2s with content | 2 credits per 10 results, plus 1 per page scraped |
| Interact | 100% (30/30) | 3.9s (code), 16s (prompt) | 2 or 7 credits per minute, 1-minute minimum |
Table 1: Overall success rate and latency
Latency roughly tracked workload: the more work a product asks of Firecrawl, the longer it took. I calculated the latency by logging the time at the beginning of each task and at its completion. For Interact, since the measure is “performing actions” and the success of those actions, I timed only the interaction itself, excluding the scrape call that opens the session. For Batch jobs and Proxy mode, only successful attempts count in the latency measurement.
Here’s why: a rate-limited job isn’t Firecrawl’s fault, but that of the target, so I wait a few seconds by default and try again, recording only the successful connections. Similarly, failed requests in the proxy tests returned quickly as Firecrawl errors, and including that in the latency calculation will give a wrong impression (faster than the real value) of the actual speed.
Scrape
As I explained in the methodology section, I added some test cases to verify Firecrawl’s core value proposition. Using Scrape, I tested Firecrawl’s conversion (HTML to Markdown) quality, caching, proxies, and extraction data formats.
For the conversion quality test, all 44 recorded strings across the 15 pages were present in the Markdown Firecrawl returned. That included code lines, Wikipedia table cells, and product prices. Table 2 covers every site I scraped during testing, not only the accuracy targets.
| Pages | Markdown tokens (median) | Raw HTML tokens (median) | Reduction |
|---|---|---|---|
| Yahoo Finance articles | 1,591 | 298,853 | 99% |
| Allbirds product pages | 6,561 | 523,411 | 99% |
| Walmart product pages | 4,805 | 230,954 | 98% |
| Leboncoin listings | 22,738 | 774,397 | 97% |
| uv documentation | 2,816 | 26,415 | 89% |
| Wikipedia articles | 30,048 | 132,672 | 77% |
| Hacker News | 6,116 | 14,687 | 58% |
Table 2: Markdown conversion quality and token savings
As the table shows, the Markdown returned saves tokens. I recorded tokens using OpenAI’s open-source library, tiktoken, so this value may differ depending on which framework you use, but the idea behind the result would be the same.
In the caching test, 7 of the 8 pages returned caches, with 5 containing outdated content. Cached results also came back faster than fresh scrapes: I recorded 0.5 - 0.9 seconds against 1.3 - 1.8 seconds for fresh scrapes, and both requests were billed the same (1 credit per successful request).
As expected, basic proxy mode recorded a low success rate against the e-commerce target and the anti-bot target, while enhanced and auto got through 100% of the time, at no extra cost. Enhanced costs the same 1 credit as basic, and auto starts on basic and escalates to enhanced on a 401, 403, or 429 response without charging for the retry. Failed requests in basic mode came back as a Firecrawl error, SCRAPE_ALL_ENGINES_FAILED, and weren’t charged, which is why basic’s average cost per request in the table below is under 1 credit.
During the tests against the e-commerce (Walmart) and anti-bot (Leboncoin) targets, no CAPTCHA pages returned as an output. However, many Leboncoin responses (across all three modes) contained DataDome’s challenge code while the complete listings were still intact. I couldn’t determine why; the practical takeaway is that the content arrived in full.
Here’s a summary of the proxy tests, recorded from my terminal log:
| Target | Basic | Enhanced | Auto |
|---|---|---|---|
| Walmart (Akamai, HUMAN) | 11 of 20 | 20 of 20 | 20 of 20 |
| Leboncoin (DataDome) | 13 of 20 | 20 of 20 | 20 of 20 |
| Average credits per request (failures not billed) | 0.55–0.62 | 1.0 | 1.0 |
Table 3: Proxy test result summary
Extraction format test evaluated the 2 ways Firecrawl pulls product fields: json and product formats. On the Allbirds product pages, both worked correctly, at 1 credit per request with the product format and 5 credits per request using the json format. On the Walmart product pages, however, the product format returned nothing. I looked a bit deeper and found it returned the error below, even though Firecrawl already loads the pages correctly.
https://www.walmart.com/ip/Apple-AirPods-4/11381374 do not appear to be a product page
https://www.walmart.com/ip/LEGO-Icons-Tranquil do not appear to be a product pageThe json format worked on the Walmart page but produced varying results between runs. It returned an incorrect price twice, with no error or warning in the response. If you rely on extracted prices, validate them against the page Markdown.
Crawl
Crawl found all 84 pages in the uv docs sitemap in both runs, with no duplicates. It also returned 3-4 pages that aren’t listed in the sitemap, so the runs returned and billed 87 and 88 pages. Crawl also runs on Scrape, so the cost remains 1 credit per returned page. Here’s my terminal log for both runs:
== crawl: uv_docs / sitemap=include / run 1
status: scraping (0/47) at 0s
status: completed (87/87) at 92s
87 pages in 92s, recall 1.0 (84/84), dups 0, non-2xx 0, creditsUsed 87, balance delta 87.0
== crawl: uv_docs / sitemap=include / run 2
status: scraping (0/0) at 0s
status: completed (88/88) at 84s
88 pages in 84s, recall 1.0 (84/84), dups 0, non-2xx 0, creditsUsed 88, balance delta 88.0recall 1.0 means that all 84 pages were found, and balance delta is the change in credit balance, which equals credits used.
Map
Map returned 106 links, 20 of which were near duplicates of URLs written slightly differently, so I cleaned the result and ended up with 83 of the 84 pages in the website’s sitemap plus 3 extra pages not in the sitemap. Here’s the terminal log of the Map runs:
Map:
uv_docs include run 1: 106 links, recall 0.988 (83/84), extra 3, 6.6s
uv_docs include run 2: 106 links, recall 0.988 (83/84), extra 3, 0.8s
uv_docs include run 3: 106 links, recall 0.988 (83/84), extra 3, 0.8s
uv_docs skip run 1: 100 links, recall 0.917 (77/84), extra 3, 0.7s
uv_docs skip run 2: 100 links, recall 0.917 (77/84), extra 3, 0.8s
uv_docs skip run 3: 100 links, recall 0.917 (77/84), extra 3, 1.1s
[map/uv_docs] 6/6 passed, credits used: 6.0 (1.0 per request)The only missing page was the starting URL. I also tested Map without the sitemap, and it returned 100 total links and 77 distinct pages.
Search
Using Search, Firecrawl returned the expected results for all 5 queries. The test ran in 2 modes: result only and result with content. A result-only search was billed at 2 credits per 10 results, and the result-with-content mode cost 1 extra credit per scraped result, so 5 results with content cost 7 credits. The table below lists the queries and the expected result pages:
| Query | Expected source |
|---|---|
| uv python package manager install guide | docs.astral.sh |
| playwright python wait for selector | playwright.dev |
| MDN fetch api response JSON | developer.mozilla.org |
| postgresql jsonb gin index | postgresql.org |
| Rust book ownership chapter | doc.rust-lang.org |
Table 4: Test queries and their expected source.
Here’s the terminal log:
== search: serp
serp 10 results, 0 with markdown, creditsUsed=2, rank of docs.astral.sh: 1 'uv python package manager install guide'
serp 10 results, 0 with markdown, creditsUsed=2, rank of playwright.dev: 1 'playwright python wait for selector'
serp 10 results, 0 with markdown, creditsUsed=2, rank of developer.mozilla.org: 1 'mdn fetch api response json'
serp 10 results, 0 with markdown, creditsUsed=2, rank of postgresql.org: 2 'postgresql jsonb gin index'
serp 10 results, 0 with markdown, creditsUsed=2, rank of doc.rust-lang.org: 1 'rust book ownership chapter'
[search/serp] 5/5 passed, credits used: 10.0 (2.0 per request)
== search: scrape
scrape 5 results, 5 with markdown, creditsUsed=7, rank of docs.astral.sh: 1 'uv python package manager install guide'
scrape 5 results, 5 with markdown, creditsUsed=7, rank of playwright.dev: 1 'playwright python wait for selector'
scrape 5 results, 5 with markdown, creditsUsed=7, rank of developer.mozilla.org: 1 'mdn fetch api response json'
scrape 5 results, 5 with markdown, creditsUsed=7, rank of postgresql.org: 2 'postgresql jsonb gin index'
scrape 5 results, 4 with markdown, creditsUsed=6, rank of doc.rust-lang.org: 1 'rust book ownership chapter'
[search/scrape] 5/5 passed, credits used: 34.0 (6.8 per request)serp represents the result-only mode and scrape is the results-with-content mode. The log shows the 5 queries and their rank: in 4 of the 5 queries, the expected source ranked first, and only came second for the PostgreSQL query.
Interact
Firecrawl Interact allows two options: AI prompt and code. I tested both, including whether a Firecrawl profile maintains an identity and IP address. Both interact options were reliable for the tasks I defined: clicking through pagination, navigating, and filling and submitting a form.
| AI prompt | Code | |
|---|---|---|
| Tasks completed correctly | 21 of 21 | 9 of 9 |
| Typical session length | 8–32 seconds | About 4 seconds |
| Credits per task, including the starting scrape | 8 | 3 |
Sessions last 10 minutes by default and are billed by browser time (2 credits per minute with code, 7 with an AI prompt), with a 1-minute minimum. That minimum is why a 4-second code task still costs 3 credits: 2 for the minute plus 1 for the starting scrape. An expired session returns one of two error codes: 409 or 410, depending on how the session starts.
In the persistent profile test, every session restored the login, cookies, and localStorage but not the IP address. While a session maintained the same IP address throughout, every new session with the same profile returned with a new IP address.
Regarding browser identity, an initial run suggested that a Firecrawl profile maintains its browser identity. But I wasn’t quite convinced, so I ran a control test and found that Firecrawl uses the same browser identity even without a profile. In other words, Firecrawl’s browser identity looks the same with or without a profile, so a profile doesn’t give you a distinct, persistent identity.
Pricing Normalized to $/1K, $/Hour, and $/GB, Plus Add-ons
Firecrawl uses a universal credit structure: each endpoint’s usage is billed from the same credit pool but with different metering units. So, your overall cost is a function of what a credit costs on your plan and how many credits the operations you run cost.
- Scrape costs 1 credit per basic fetch, with any proxy mode, and 5 credits per
jsonformat request. - Crawl is billed at 1 credit per returned page, including pages outside the sitemap.
- A Map call costs 1 credit.
- Search costs 2 credits per 10 results with no page content plus 1 credit per result you scrape. For example, 5 results with content cost 7 credits.
- Interact is billed 3 credits per coded task (as tested) and 8 credits per AI-prompted task (as tested).
Here’s a table showing the costs per credit based on your Firecrawl plan:
| Plan | Monthly price | Credits a month | Cost per 1,000 credits | Concurrent browsers | Pay-as-you-go credits per $5 |
|---|---|---|---|---|---|
| Free | $0 | 1,000 | n/a | 2 | n/a |
| Hobby | $19 ($16 yearly) | 5,000 | $3.80 ($3.20 yearly) | 5 | 1,000 |
| Standard | $99 ($83 yearly) | 100,000 | $0.99 ($0.83 yearly) | 25 | 2,000 |
| Growth | $399 ($333 yearly) | 500,000 | $0.80 ($0.67 yearly) | 50 | 2,500 |
| Scale | $749 ($599 yearly) | 1,000,000 | $0.75 ($0.60 yearly) | 100 | 5,000 |
Here’s another table showing the cost per 1000 operations for Hobby and Standard plans, using monthly prices:
| Operation | Credits | Hobby | Standard |
|---|---|---|---|
| Scrape a page (any proxy mode) | 1 | $3.80 | $0.99 |
| Scrape with JSON extraction | 5 | $19.00 | $4.95 |
| Crawl a page | 1 | $3.80 | $0.99 |
| Map a site | 1 per call | $3.80 | $0.99 |
| Search, 10 results, no content | 2 | $7.60 | $1.98 |
| Search, 5 results with content | 7 | $26.60 | $6.93 |
| Interact task by code, as tested | 3 | $11.40 | $2.97 |
| Interact task by prompt, as tested | 8 | $30.40 | $7.92 |
Cost per Hour
Interact is the only Firecrawl endpoint billed by time, costing 2 credits per browser minute with code and 7 per AI prompt. That amounts to about $0.46 per hour on the Hobby plan and $0.12 per hour on Standard for sessions run on code. Similarly, AI-prompted sessions cost $1.60 and $0.42 on Hobby and Standard, respectively.
Cost per GB
Firecrawl doesn’t meter bandwidth, so there’s no native $/GB price. A 2 MB product page costs the same 1 credit as a 90 KB docs page. In my test, Leboncoin category pages were about 2.3MB of HTML each. At Standard’s $0.99 per 1,000 pages, 1,000 requests work out to roughly $0.43 per GB of source HTML. Similarly, the documentation pages were about 90 KB each, putting the same price at about $11 per GB. Per-page billing favors heavy pages and penalizes light ones, which is the opposite of per-GB proxy pricing.
What’s Included vs. What Costs Extra
Here’s what every plan includes and what costs extra:
| Item | Status | Notes |
|---|---|---|
| Proxies (basic, enhanced, auto) | Included | No surcharge for enhanced; standalone proxies are not sold |
| JavaScript rendering, anti-bot handling | Included | Worked against Akamai, HUMAN, and DataDome in my tests |
| CAPTCHA solving | Not a billed line item | Not listed as an add-on; no CAPTCHA page reached the output in my tests |
| Storage | No storage fee | Results come back in the response; Zero Data Retention is Enterprise-only and adds 2 credits/min to Interact |
| LLM formats (JSON, question, highlight) | +4 credits per page | Applies to Scrape and Crawl |
| AI-prompted Interact | 7 vs. 2 credits/min | 3.5x the cost of code-driven sessions |
| Monitor | 1 credit per page per check | 7 credits with the deterministic extraction engine |
| Agent | 5 free runs a day | Dynamic pricing after that (preview) |
| Extra credits | $5 increments | 1,000 (Hobby) to 5,000 (Scale) credits per $5; purchased credits expire if you cancel |
| Unused credits | Roll over on Scale only | One month on Scale; custom on Enterprise; lost on Hobby, Standard, Growth |
| Error pages (403, 404) | 1 credit | Only requests that return no document are free |
Why the Units Don’t Line Up
One credit pool doesn’t mean one unit. Take a 500-page product catalog. Map plus Scrape costs 501 credits. Crawl costs 500 or more, because it also bills for pages outside the sitemap (3-4 extra in my test). Adding json extraction to either takes it to roughly 2,500 credits. If the catalog sits behind a login, Interact bills by the minute instead, so the cost depends on how fast the site responds, not on how many pages you read. You can’t compare these upfront without testing your own targets.
Pros
- Accurate conversion from raw HTML to Markdown. All 44 strings recorded to test against Firecrawl’s conversion quality were present in the returned Markdown. Content pages shrank by 77-99% in tokens, which directly cuts LLM costs.
- Firecrawl’s defaults work on protected pages and also handle JavaScript rendering, even with no user configuration. The default auto mode got through 40 of 40 requests to Akamai-, HUMAN-, and DataDome-protected pages.
- Failed requests that return nothing are free. Every
SCRAPE_ALL_ENGINES_FAILEDresponse in my tests cost 0 credits; note that 403/404 pages that return a document are still billed. - One API key and a single credit balance for all products make it easy to integrate with other tools.
- No proxy surcharge. Enhanced proxies cost the same 1 credit as basic ones, and auto-escalation retries aren’t billed.
- Fast, cheap discovery. Map listed 83 of 84 sitemap pages in under a second for 1 credit, and Crawl fetched the whole 84-page site in about 90 seconds.
- Reliable browser automation. Interact completed 30 of 30 tasks in both code and AI-prompt modes.
Limitations
- Firecrawl profiles maintain login, cookies, and localStorage, but not IP address. Every new session came from a new IP (7 of 7), and the fingerprint was the same with or without a profile, so a profile does not give you a distinct identity.
- The default cache can return outdated pages. In the cache test, 5 of the 7 cache returns differed from the corresponding fresh scrapes. Set
maxAge: 0for anything time-sensitive. - The
productformat for extracting product data is inconsistent. It returned no values at all from Walmart product pages. Thejsonformat returned a wrong price twice with no warning, at 5x the cost of a basic scrape. - Errors are hard to debug; they don’t explain themselves. Failed requests in the basic proxy mode test returned the error
SCRAPE_ALL_ENGINES_FAILED, which isn’t that helpful. - Billing units that don’t compare. Pages, calls, 10-result blocks, and browser minutes make it hard to forecast spend across endpoints. The 1-minute Interact minimum means a 4-second task is billed as a full minute.
- Error pages are billed. A page that comes back with a 403 or 404 still costs 1 credit; only requests that return no document are free.
- Plan-gated controls. Ignoring robots.txt and Zero Data Retention require Enterprise, and unused credits roll over only on Scale and Enterprise.
Firecrawl vs. Gologin
None of the limitations above affect Firecrawl’s ability to load a page, including pages behind advanced anti-bot protection: it got through 100% of Walmart and Leboncoin requests. So getting blocked isn’t a reason to look elsewhere, but you may want other options if cost or what carries over from one session to the next matters for your use case.
Gologin covers these gaps with two products: Web Unlocker, which returns any page’s HTML, and Cloud Browser, which persists profiles, including the proxy (and therefore the IP address, when you use a static or sticky proxy).
| Metric | Firecrawl (based on my test data) | Gologin |
|---|---|---|
| Core product | Web data API: Scrape, Crawl, Map, Search, Interact | Persistent browser profiles, run locally or via Cloud Browser; Web Unlocker API for single pages |
| Page output | Markdown, JSON, product data, HTML, screenshots | Rendered HTML, JSON, Markdown, screenshots (Web Unlocker) |
| Protected sites | 100% success with default config on Walmart and Leboncoin | Residential IPs and browser fingerprints included (Web Unlocker) |
| Failed requests | Free if no document is returned; 403/404 pages are billed | Free (Web Unlocker) |
| Price per 1,000 pages | $3.80 (Hobby) to $0.75 (Scale) per 1,000 credits | $0.98 to $0.45 per 1,000 successful requests, by tier (Web Unlocker) |
| Browser sessions | Interact: 2 credits/min (code) or 7 (AI prompt), 1-minute minimum, 10-minute default lifetime | Cloud Browser: standard CDP endpoint, billed hourly, 100–400 hours included depending on plan |
| What a saved profile keeps | Cookies and localStorage, restored in 7 of 7 sessions over 12 hours | Cookies/storage + fingerprint and proxy settings (IP address) |
| IP across sessions | New IP in every session (7 of 7) | Proxy stored in the profile; same IP with a static or sticky proxy |
| Logged-in pages | Only through an Interact session | Through a profile session in Cloud Browser |
| Standalone proxies | Not offered (proxies included in requests by default) | Sold separately; paid plans include 2 GB of residential traffic |
The two tools solve different halves of the same problem. Firecrawl is the better pick when the output is the point: public pages turned into clean Markdown or JSON for an LLM, billed per page with proxies included. In my tests, it got through Akamai, HUMAN, and DataDome without any configuration.
Gologin is built around identity rather than output. A Gologin profile stores the browser fingerprint, cookies, storage, and proxy settings together, and Cloud Browser runs that profile over a standard CDP endpoint, so existing Playwright or Puppeteer code connects without a rewrite. That matters for logged-in workflows, such as account dashboards, marketplaces, and social platforms, where the site expects the same returning user. Firecrawl’s Interact profile kept my login but presented a new IP in 7 of 7 sessions, with a fingerprint that didn’t change even without a profile.
The pricing models differ too. Firecrawl bills credits per page, call, or minute; Gologin bills Cloud Browser by the hour, Web Unlocker per successful request, and proxies per GB or per IP. For high-volume extraction of public pages, Firecrawl’s per-page model is simpler. For long-lived sessions on sites that check whether a returning user looks consistent, Gologin’s hourly browser with a stored proxy is the closer fit.
One Key, One Identity: What Survives When the Browser Closes
The Firecrawl profile from my test maintains the login and localStorage but changes the IP address with every new session. In a real-world scenario, what the target sees is a new user who happens to have the same browser identity from a completely different location.
Modern websites track these signals and more, so any mismatch raises suspicion and can result in a blocked request. Gologin Cloud Browser stores everything in the profile, including the proxy you assign to it, and presents the same values on every visit. Attach a static ISP or sticky residential proxy, and the target sees the same IP address it saw at your first login. (A rotating proxy will still change the IP between sessions.)
With Gologin, the browser itself is disposable: log in once, close the session, and reconnect as the exact same user on every request.
Cloud Browser connects over CDP, so your existing Playwright or Puppeteer script needs only a connection URL:
wss://cloudbrowser.gologin.com/connect?token={TOKEN}&profile={profileId}Here’s an example that runs a saved profile twice, 1 hour apart, logs the IP for each session, and stops the profile when it’s done.
import asyncio
import json
import os
from datetime import datetime, timezone
import requests
from dotenv import load_dotenv
from playwright.async_api import async_playwright
load_dotenv()
TOKEN = os.environ["GL_API_TOKEN"]
PROFILE_ID = os.environ["GL_PROFILE_ID"]
CDP_URL = f"wss://cloudbrowser.gologin.com/connect?token={TOKEN}&profile={PROFILE_ID}"
STOP_URL = f"https://api.gologin.com/browser/{PROFILE_ID}/web"
SESSIONS = 2
GAP_SECONDS = 3600 # one hour between session starts
def check_start():
r = requests.get(CDP_URL.replace("wss://", "https://"), timeout=60)
if not r.ok:
reason = r.headers.get("X-Error-Reason") or r.status_code
raise RuntimeError(f"Cloud Browser didn't start: {reason}")
async def session(n):
check_start()
try:
async with async_playwright() as p:
browser = await p.chromium.connect_over_cdp(CDP_URL)
context = browser.contexts[0] if browser.contexts else await browser.new_context()
page = await context.new_page()
await page.goto("https://api.ipify.org?format=json", wait_until="domcontentloaded")
ip = json.loads(await page.inner_text("body"))["ip"]
await browser.close()
finally:
requests.delete(STOP_URL, headers={"Authorization": f"Bearer {TOKEN}"}, timeout=60)
ts = datetime.now(timezone.utc).isoformat(timespec="seconds")
print(f"session {n} {ts} IP {ip}", flush=True)
async def main():
start = asyncio.get_running_loop().time()
for n in range(1, SESSIONS + 1):
try:
await session(n)
except Exception as e:
print(f"session {n} failed: {e}", flush=True)
if n < SESSIONS:
wait = start + n * GAP_SECONDS - asyncio.get_running_loop().time()
if wait > 0:
print(f" next session in {wait / 60:.0f} min", flush=True)
await asyncio.sleep(wait)
asyncio.run(main())Run it with a static ISP proxy attached to the profile, and both sessions should report the same IP address. With a rotating proxy, the IP can change between sessions, so how long an address lasts depends on the proxy you attach to the profile.
FAQ
Is Firecrawl free?
Yes, up to a point. The Free plan includes 1,000 credits that refresh every month, with 2 concurrent browsers and no credit card required. Paid plans start at $19 a month (Hobby, 5,000 credits).
How much does a Firecrawl scrape cost?
A standard Firecrawl scrape costs 1 credit and works on protected pages and JavaScript-heavy pages with no configuration required. A json format extraction for product data raises the cost to 5 credits per page. In dollars, that’s $3.80 per 1,000 pages on Hobby and $0.99 on Standard.
What’s the difference between Firecrawl Scrape, Crawl, and Map?
Scrape fetches one URL you already have. Map lists the URLs on a site for 1 credit per call without fetching their content. Crawl discovers and scrapes every page on a site or section, at 1 credit per returned page.
Does Firecrawl return cached pages?
Firecrawl serves cached pages up to two days old by default. To force a fresh scrape, set the maxAge parameter to 0. In my test, 5 of 7 cached responses were outdated.
Does Firecrawl charge for failed requests?
Not when no document is returned: failed requests such as SCRAPE_ALL_ENGINES_FAILED cost 0 credits. But a page that returns an error status, such as 403 or 404, still costs 1 credit.
Does a Firecrawl profile keep the same IP address?
No. In my test, an Interact profile kept the login, cookies, and localStorage across 7 sessions over 12 hours, but each session came from a different IP address.
When should I use Gologin instead of Firecrawl?
Use Firecrawl when your use case requires turning public pages into clean Markdown. Use Gologin when your target site needs to see the same returning user every run. Gologin Cloud Browser persists everything from your first login, including proxy settings.
Conclusion
Firecrawl delivers on its value proposition: a web data API for AI agents. All 44 strings recorded for the conversion quality test, across multiple pages, were accurately returned as Markdown. It also handled anti-bot and e-commerce targets automatically, with no configuration required.
However, the default cached results, up to two days old, can result in unwanted outcomes, and its product and json formats for retrieving product data are inconsistent. The product format returned nothing from multiple Walmart pages, while the json format requests returned an incorrect price value twice, with no visible explanation.
What to actually buy: start on the Free plan to measure your own credit usage. Hobby suits prototypes; Standard ($0.99 per 1,000 pages) is the realistic floor for production scraping.
Firecrawl also doesn’t persist IP addresses between sessions. If your use case requires staying signed in as the same returning user, consider the Gologin Cloud Browser. Each profile stores the cookies, browser fingerprint, localStorage, and proxy, run after run, so with a static proxy the IP address stays the same too. On run 100, the site sees the same user it saw on run 1.
Try it yourself: create a free Gologin account, attach a static proxy to a profile, and point your existing Playwright or Puppeteer script at Cloud Browser with a single connection URL.
