By the fastCRW team · Competitor multipliers reportedly verified 2026-05-18 (volatile — re-verify against ScrapingBee's live pricing) · fastCRW launch pricing expires 2026-06-01 · Verify independently before buying.
Disclosure: We build fastCRW, so weight this comparison accordingly. We have kept the ScrapingBee figures explicitly "reportedly" and dated, run all worked cost math only on fastCRW's frozen credit side, and included a section on where ScrapingBee genuinely wins. A comparison that pretends the competitor has no advantages is not useful to you.
ScrapingBee JS rendering cost: the multiplier in one paragraph
The ScrapingBee JS rendering cost is the thing that surprises most developers scraping modern, JavaScript-heavy sites: rendering JavaScript does not cost one credit per request, it costs a multiple of the base request. Per our competitor profiling (dated 2026-05-18, flagged volatile), ScrapingBee reportedly applies a JS-rendering multiplier of roughly 5× on top of the base credit, and the render_js parameter is on by default — so a request you thought cost one unit can quietly cost several. The contrast we will draw is simple: fastCRW prices a JavaScript-rendered scrape at a flat 2 credits (1 credit for an http or lightpanda fetch) on every tier, including the fastCRW pricing, per our pricing and the canonical credit table. None of the ScrapingBee numbers below are locked facts; treat them as illustrative mechanics and confirm against ScrapingBee's live pricing page before you budget.
What ScrapingBee charges for JS rendering
Three mechanics are worth understanding before you read a ScrapingBee invoice. All three are reported from competitor profiling dated 2026-05-18 and flagged as volatile/uncertain — re-verify them yourself.
- The JS-rendering multiplier (reportedly ~5×). A standard HTML fetch costs the base credit; turning on JavaScript rendering reportedly multiplies that by around five. Because
render_jsdefaults to on, the multiplier is the common case, not the exception — the footgun is that you opt out of the cost, not into it. - Premium and stealth proxy multipliers (reportedly 25–75×). Routing through premium or stealth residential proxies reportedly stacks a far larger multiplier on top. For anti-bot-heavy targets this is where the real cost lives, and it compounds with the JS multiplier.
- Tier gating. JS rendering and the deeper proxy features are reportedly available only on higher-priced tiers. We deliberately do not quote a frozen ScrapingBee tier dollar here — that pricing is not in our locked source set, and tier prices move. Check ScrapingBee's live pricing page for the current numbers.
The single most important takeaway is the pattern, not any one figure: on a multiplier model, your effective cost per page is the base credit times whatever multipliers your request triggered. On JS-heavy sites that is the normal path, so the headline credit count understates your real spend.
The hidden cost of a default-on multiplier
A default-on JS multiplier has two compounding effects on a real workload.
First, it makes entry tiers effectively non-functional for modern sites. If a tier advertises, say, a fixed credit allowance and most of your targets need JavaScript, a reportedly ~5× multiplier means your usable request count is roughly a fifth of the headline number. You are not buying the credits you think you are buying — you are buying credits divided by the multiplier you happen to trigger.
Second, it makes forecasting hard. With a per-feature multiplier you cannot estimate a monthly bill from page volume alone; you need to know, per page, which renderer and which proxy class fired. That is exactly the unpredictability we describe in credit-based pricing explained. The deeper the multiplier stack, the further your worst case drifts from your planning number — and the worst case is the number that blows a budget.
How fastCRW prices a JS render
fastCRW meters a single dimension: pages, by renderer. The credit table is short and frozen.
| Operation | Credits (fastCRW) |
|---|---|
Scrape, http or lightpanda renderer | 1 |
Scrape, chrome renderer (full JS) | 2 |
| Crawl | 1 per page (2 per page when chrome-rendered) |
| Search | 1 per query |
| Map | 1 |
extract / any request with formats: ["json"] | 5 |
A JavaScript-rendered scrape is a flat 2 credits. Not 1 credit times a multiplier — a fixed 2 credits, every time, on every plan. There is no separate "JS rendering" line item and no tier wall: the full API surface is available on every tier, including the free tier (500 one-time lifetime credits).
The renderer is also adaptive. The default auto mode auto-selects with a chrome → lightpanda → http fallback, so a page that does not actually need a headless browser is fetched at 1 credit, and only pages that genuinely require JavaScript escalate to the 2-credit chrome path. You can also pin http, lightpanda, or chrome explicitly. The practical effect: on a mixed workload, most pages stay at 1 credit and the JS-heavy ones cost 2 — a one-credit delta, not a five-fold one.
And the cost ceiling is real: the engine is a single static Rust binary under AGPL-3.0, so self-hosting the same chrome renderer costs $0 per 1,000 scrapes (you pay only your own server). That floor is something a hosted-only multiplier model structurally cannot offer.
Honest gap: anti-bot and proxy depth
This is where the comparison has to be fair. fastCRW does not have ScrapingBee's proxy and anti-bot depth, and pretending otherwise would be dishonest:
- No Fire-engine-class anti-bot. fastCRW has no heavy managed anti-bot stack. It uses a chrome-stealth fallback, but it is not a dedicated bypass engine.
- No residential proxy pool. There is no built-in premium/stealth residential proxy network. If your targets demand rotating residential IPs to load at all, that is a gap.
- Stateless per request. fastCRW holds no persistent session or browser state between requests.
Where ScrapingBee genuinely wins: for aggressively bot-protected targets — sites that hard-block datacenter IPs or require deep residential rotation — ScrapingBee's Oxylabs-backed proxy depth and managed anti-bot are a real, paid-for capability that fastCRW does not match. If your scraping is gated on that proxy depth, the multiplier is buying you something fastCRW cannot, and that is a legitimate reason to pay it. The multiplier model is the wrong shape when JavaScript rendering is the only reason you are paying it; it is the right shape when you are paying for industrial-grade evasion.
Cost comparison for a JS-heavy workload
Here is the worked math — and note that we run it only on fastCRW's frozen credit side. The ScrapingBee column is shown as the reportedly ~5× JS multiplier applied to a base unit, illustrative only; we do not fix a ScrapingBee dollar total because that pricing is not locked.
| Scenario (1,000 JS-heavy pages) | fastCRW credits | Multiplier-model effective cost |
|---|---|---|
| All pages need full JS render | 2,000 credits (2 × 1,000) | ~5× base per page (illustrative) |
| Auto renderer — ~60% need JS, ~40% http | ~1,600 credits | ~5× on the JS share (illustrative) |
| Self-hosted (AGPL-3.0) | $0 per 1,000 scrapes + your server | n/a — no hosted multiplier path |
To turn fastCRW credits into dollars, divide by your plan's credit allowance — derive the per-page cost from your tier on the live pricing page rather than from a hard-coded table, since launch pricing reverts on 2026-06-01. The structural point survives whatever the exact dollars are: fastCRW's worst case for a JS render is a fixed 2 credits, while a multiplier model's worst case is the base credit times whatever multipliers fire — and that worst case is unbounded by tier, not by page. For deeper background on how the two ScrapingBee tiers and credit mechanics work, see ScrapingBee pricing explained; for a full feature head-to-head, see ScrapingBee vs fastCRW; and for the proxy/anti-bot landscape, see anti-bot and proxies overview.
Who should pick which
If your bottleneck is JavaScript rendering on otherwise reachable sites — SPAs, client-rendered content, lazy-loaded data — a flat 2-credit render with a free self-host floor is the more forecastable shape, and that is fastCRW's case. If your bottleneck is anti-bot evasion on hostile targets that need residential proxy rotation to load at all, ScrapingBee's multiplier is buying proxy depth fastCRW does not have, and paying it is rational. Most JS-heavy workloads are the first kind; the honest exception is the second.
Sources
- ScrapingBee JS multiplier (reportedly ~5×), premium/stealth proxy multipliers (reportedly 25–75×), and tier gating: competitor profiling dated 2026-05-18 — flagged volatile/uncertain, NOT a locked price. Re-verify at scrapingbee.com/pricing
- fastCRW repo and live pricing: github.com/us/crw · fastcrw.com · /pricing
Related: ScrapingBee pricing explained · ScrapingBee vs fastCRW · Credit-based pricing explained · Anti-bot and proxies overview