By the fastCRW team · fastCRW features verified 2026-05-18 · fastCRW launch pricing expired 2026-06-01 — see the live pricing page for current rates · Verify competitor prices on the vendor pricing page before buying.
Disclosure: We build fastCRW, so weight this comparison accordingly. We have kept the ScrapingBee and Bright Data wins explicit, and we deliberately do not hard-code competitor tier prices — those move, so we link the live vendor pricing pages and stick to the billing mechanics, which are stable.
ScrapingBee vs Bright Data vs fastCRW pricing: three billing models, one confusing bill
If you are comparing ScrapingBee, Bright Data, and fastCRW on price, the hard part is not the sticker number — it is that the three vendors charge for fundamentally different units. ScrapingBee bills credits with a multiplier that changes per request. Bright Data bills proxy bandwidth (GB) plus per-request fees that stack. fastCRW bills a flat 1 credit per page, and you can also run the exact same engine yourself for $0 in license fees. Until you normalize those units, every published comparison table is comparing apples, gigabytes, and binaries.
ScrapingBee: credit multipliers per request
ScrapingBee sells a monthly credit bucket, but a single request does not always cost one credit. A plain HTML fetch is cheap; turning on JavaScript rendering multiplies the cost, and premium or stealth proxies multiply it again. The mechanic that surprises people on their first invoice is that the page count and the credit count diverge — JS-rendered pages do not map 1:1 to credits. We deliberately do not quote the exact multipliers here because they are unverified against our locked sources and they move; confirm both the multipliers and the dollar tiers on the ScrapingBee pricing page before you budget.
Bright Data: proxy GB plus per-request stacking
Bright Data is a proxy-network company first. Its pricing centers on residential and datacenter bandwidth consumed (priced per GB) layered with per-request or per-feature charges depending on the product (Web Unlocker, SERP API, Scraping Browser, datasets). For a data team this means your bill is a function of how heavy your target pages are, not just how many you fetch — image-heavy or single-page-app targets can quietly burn GB. Verify the current model on the Bright Data pricing page.
fastCRW: 1 credit = 1 page, flat
fastCRW collapses the model to one number. Every renderer — http, lightpanda, and Chrome — costs 1 credit per page, flat; a crawl is 1 credit per page regardless of renderer; search is 1 credit per query (credit table, crw-opencore README). There is no proxy-GB meter and no per-feature multiplier, because fastCRW does not operate a residential proxy network at all — more on that honest gap below.
ScrapingBee vs Bright Data: where the money actually goes
The credit-multiplier model: JS and stealth stack the per-request cost
The single most important ScrapingBee mechanic to internalize is the multiplier ladder: JavaScript rendering multiplies the per-request credit cost, and premium or stealth proxies multiply it further still. That is not a gotcha — it is a defensible way to price the real cost of a headless browser and a clean residential IP. But it means your effective price per page depends entirely on which requests need JS or stealth, which you often cannot predict before you start scraping. We do not quote the exact multipliers here; read them off the live ScrapingBee pricing page, since they change and are not locked in our sources.
JS rendering gated to a higher paid tier — check the vendor pricing page
On several scraping vendors, JavaScript rendering and premium proxies are not just credit-expensive, they are also gated behind a higher paid plan. The practical effect is that the entry tier looks cheap until you hit a JS-heavy target, then you are pushed up a plan and paying a multiplier. We will not assert a specific JS-paywall dollar figure here because those tiers change; the durable point is to read the feature matrix, not just the headline price, on the live pricing page before you commit budget.
What a real 100k-page month costs on each
Here is why a clean side-by-side table is dishonest for these two vendors: the answer is "it depends on your traffic mix." A 100,000-page month of static HTML is cheap on ScrapingBee and light on Bright Data GB. The same 100,000 pages, if they are JavaScript-heavy and bot-protected, burn far more credits on ScrapingBee (each JS or stealth request carries a multiplier) and many GB of residential bandwidth on Bright Data. Model your own mix against each vendor's live calculator rather than trusting any third-party table (including this one).
The honest third option: fastCRW pricing
Flat per-page credits, full API on every plan
fastCRW's managed tiers are deliberately boring: a flat credit-per-page rate with the full API surface (scrape, crawl, map, search) available on every plan — no feature gating that pushes JS rendering or extraction behind a higher tier. The lineup runs from a free tier (one-time lifetime credits, no card) through Hobby, Standard, Growth and Scale, each a larger monthly credit bucket at the same flat per-page rate. Prices move and the early-2026 launch discount has already lapsed, so we do not reprint a tier table here — check the current numbers on the live pricing page rather than treating any quoted figure as permanent.
Self-hosting the AGPL-3.0 engine for $0
The structural difference neither closed vendor can match: fastCRW is a single static Rust binary released under AGPL-3.0 (repo github.com/us/crw). You can run the identical engine yourself for $0 per 1,000 scrapes in license fees — you pay only for your own server. There is no credit meter when you self-host, because there is no vendor in the loop. That is an escape hatch a proxy-network business and a managed credit API are structurally unable to offer.
The unit stays flat as prices change
Being straight about our own pricing: tier dollar figures change over time, and the early-launch discount that ran into mid-2026 has since lapsed. What does not change is the unit — a flat credit per page with no JS or stealth multiplier — so your spend stays forecastable regardless of which tier you land on. Price your decision on the numbers live on /pricing the day you buy, not on a blog snapshot.
Cost at scale: managed vs self-hosted math
Self-hosted: $0 per 1,000 scrapes plus your server
At volume, the self-host math is what changes the conversation. fastCRW self-hosted is $0 per 1,000 scrapes in license cost; your only spend is the box it runs on, and because the engine is a single ~8 MB binary in one container, that box can be small. For a team running millions of pages a month on predictable, non-hostile targets, a fixed server bill can undercut any per-credit or per-GB meter by a wide margin — and your worst-case cost has a hard floor, which a metered model structurally cannot offer. See our deeper write-up on the cheapest web scraping API options for the full math.
When a managed tier still wins on operational cost
Self-hosting is not free in the honest sense — it costs engineering time. If your volume is modest, your targets change often, or you do not want to own uptime, the managed fastCRW tiers (or even a competitor's managed plan) will beat self-host on total cost once you price in the hours. The flat credit model just makes that managed bill predictable: 1 page is 1 credit whether or not it needed JS, so you can forecast spend without modeling a multiplier distribution.
Where ScrapingBee and Bright Data genuinely win
An honest three-way comparison has to concede the rows where fastCRW simply does not compete:
- Bright Data's residential proxy depth and anti-bot. Bright Data operates one of the largest residential proxy pools in the industry (reported 100M+ IPs) with mature anti-bot unlocking. fastCRW has no built-in residential proxy network and no Fire-engine-style anti-bot layer. For hostile, heavily bot-protected, or geo-locked targets at scale, that proxy depth is the whole product, and fastCRW does not pretend to match it.
- ScrapingBee's mature proxy reliability. ScrapingBee has spent years tuning proxy rotation and JS rendering into a reliable managed service. If you want to send a URL and never think about IPs, retries, or headless browser fleets, that maturity is worth the multiplier. fastCRW is leaner and self-hostable, but it is a younger engine without that operated-proxy track record.
- Bandwidth-priced fairness for light pages. Bright Data's per-GB model can actually be cheaper than per-page credits when your targets are tiny JSON or text endpoints — you pay for the few KB you pulled, not a flat page fee.
The wedge fastCRW owns is narrow and clear: a flat 1-credit-per-page model with a free, AGPL-3.0 self-host escape hatch. If your targets are not hostile and you value predictable, forecastable cost (or want to eliminate vendor cost entirely), that is the lane. If you need an industrial residential proxy network with anti-bot baked in, buy the proxy giant.
Sources
- fastCRW pricing, credit costs, footprint, and honest gaps: github.com/us/crw · fastcrw.com/pricing
- ScrapingBee credit multipliers and tiers: scrapingbee.com/pricing (mechanics stable as of 2026-05; verify dollar tiers)
- Bright Data proxy-GB and per-request pricing: brightdata.com/pricing (verify before buying)
Related: ScrapingBee vs fastCRW · Bright Data vs fastCRW · The cheapest web scraping API