ScrapingBee pricing, ZenRows pricing and Scrapfly pricing: what a credit actually buys at each

All three of these vendors sell credits rather than requests, and at two of the three a JavaScript rendered page costs exactly 5 credits. That makes ScrapingBee and ZenRows directly comparable, and on the comparable tiers ScrapingBee is cheaper per rendered page at every step of the ladder. Scrapfly sells credits too but does not publish what each feature consumes, so its plans cannot be normalized from public information at all. Every figure and quotation below was read off the vendors own pricing pages and documentation on 2 September 2026.

The reason this comparison is worth doing carefully is that the headline plan prices are close enough to look like a coin flip. ZenRows Build is $16 a month, ScrapingBee Hobby is $19, Scrapfly Discovery is $30. Those three numbers tell you almost nothing, because the plans contain 45,000, 75,000 and 200,000 credits respectively, and a credit is not the same size at each vendor.

What each vendor charges per credit

Start with the plans as published, then divide. This is the only comparison that does not require knowing what a credit buys.

Two things stand out. Scrapfly is much the cheapest per credit at the entry tier, $0.150 against $0.253 and $0.356, and it is also the only one of the three that gives you just 5 concurrent requests at that price. And by the top of each ladder the three converge hard, to $0.075, $0.091 and $0.091. This is a mature market that has settled on roughly the same wholesale number, and the differences that remain are at the bottom of the ladder and in what a credit actually pays for.

How many credits does a JavaScript rendered page cost?

Five, at both vendors that publish the figure. ScrapingBee documentation says JavaScript rendering "is the default behavior and costs 5 credits per request". ZenRows publishes the same structure: one credit for a standard successful page, and JavaScript rendering at 5 credits. Because the multiplier is identical, the per credit column above converts cleanly into a per page price for those two.

Read across the pairs that sit closest in price and ScrapingBee wins each one, by roughly 30 percent at the bottom and 20 percent at the top. The $49 Freelance plan and the $57 Launch plan both include exactly 250,000 credits, which is as close to a controlled comparison as this market offers, and ScrapingBee is $8 a month cheaper for the same allowance with the same 50 concurrent requests.

That is not the end of the decision, because the two products differ in ways a credit count does not capture, and because ZenRows publishes a residential bandwidth rate that ScrapingBee handles differently. But if your workload is ordinary JavaScript rendered pages on sites that are not actively fighting you, ScrapingBee is the cheaper of the two at every comparable tier, and it is worth knowing that before a trial pushes you either way.

The anti-bot multiplier is where the bill actually moves

Standard rendering is the cheap case. What decides most real invoices is what happens when the target site has protection on it, and here the published multipliers are large enough to change your plan choice by two tiers.

ScrapingBee premium proxy costs 25 credits with JavaScript enabled, and its documentation is precise about the variant: "If used without JavaScript rendering it will cost 10 credits". ZenRows charges 10 credits for premium proxies and 25 for premium proxies plus JavaScript rendering, which is the same shape and the same top number. So on protected pages the two vendors are once again on identical multipliers, and a protected page costs five times what an ordinary rendered page costs at both.

Then ScrapingBee publishes one figure that has no equivalent on the other two rate cards. Its stealth proxy option states that "Each successful API call using this option will cost 75 credits". That is fifteen times a standard JavaScript rendered request. On the $19 Hobby plan, 75,000 credits buys 15,000 ordinary rendered pages, 3,000 premium proxy pages, or exactly 1,000 stealth pages. The same plan, the same money, and a fifteenfold difference in what you get, decided entirely by one query parameter.

ZenRows prices its hardest cases through bandwidth instead, at 25,000 credits per GB of residential traffic, which it describes as roughly 1,000 protected pages. On the $165 Growth plan with 1.2M credits, that is about 48GB, or somewhere near 48,000 protected pages if the estimate holds for your targets. Bandwidth based pricing is harder to forecast than a per request multiplier, because it depends on page weight rather than page count, and image heavy targets will consume it far faster than the estimate suggests.

The practical consequence is that you cannot budget any of these services from a page count alone. You need a page count split by protection level, and most teams only discover that split after they start. Run a few hundred requests against your real target list before choosing a tier, and count how many needed the expensive path.

Scrapfly does not publish what a feature costs

Scrapfly has the cheapest entry credit rate in the table and the most generous credit allowances, and it is the one vendor of the three whose plans cannot be converted into a price per page from published information. Its pricing page states that "Credit cost per request depends on the features you enable (JavaScript rendering, ASP, residential proxies, country targeting, etc.)" and routes you to a cost estimator rather than a published multiplier table.

That is not a criticism of the product, and the estimator is a reasonable way to handle a genuinely multi dimensional price. It is a limitation on what you can conclude before signing up. If a standard Scrapfly request with JavaScript rendering costs 5 credits, as it does at both competitors, then Discovery at $30 for 200,000 credits is 40,000 rendered pages for $0.75 per 1,000, which would make it comfortably the cheapest entry plan of the three. If it costs more than 5, the advantage shrinks or disappears. We are not going to print the first number as though it were a fact, because Scrapfly does not publish the multiplier it depends on.

What Scrapfly does publish, and what the other two do not put as plainly, is its overage. "Extra credits (per 10k): Discovery $5.00, Pro $3.50, Startup $2.00, Enterprise $1.20". Compare that with the in plan rate and the gap is the interesting part. Discovery credits inside the plan cost $0.150 per 1,000. Extra credits on the same plan cost $0.500 per 1,000, which is 3.3 times the in plan rate. On Pro the in plan rate is $0.100 and the overage is $0.350, again 3.5 times. Scrapfly notes that "Pro and above switch to pay-as-you-go when included credits are consumed", so your integration keeps working, at triple the unit price. Sizing the plan slightly too small is therefore an expensive mistake here in a way it is not at a vendor that simply stops.

Concurrency, the limit that is not about money

The column most buyers skim is often the one that decides whether a plan can do the job at all. Scrapfly Discovery has the cheapest credits in the table and 5 concurrent requests. ScrapingBee Hobby, at nearly double the credit price, has 25. ZenRows Build has 20.

If you need to refresh 50,000 pages inside a nightly window, concurrency and not credit price sets whether that is possible. At 5 concurrent requests and a two second average response, you clear roughly 9,000 pages an hour. At 100 concurrent you clear roughly 180,000. Teams routinely buy the cheap plan on credits, discover the throughput ceiling in week two, and move up two tiers, at which point the per credit advantage that drove the original choice has usually evaporated. Work out your required throughput first, filter the plans that can deliver it, and only then compare price.

What none of the three prices is the part after the fetch

Every figure on this page buys you the same thing: raw HTML retrieved from a page that did not want to give it to you. That is genuinely hard and worth paying for. It is also only the first half of most projects, because HTML full of navigation, cookie banners, ad slots and script tags is not usable input for anything downstream. The second half, turning that markup into clean structured data a model can actually read, is a separate problem with a separate cost, and teams that budget only for the fetch tend to spend the difference in engineering time writing and re-writing selectors that break whenever the target site ships a redesign.

It is worth deciding which half you are actually buying before you compare rate cards. If your targets are stable and you already have parsers, a fetch API priced on credits is exactly right. If the target list changes often, the extraction is the expensive part and the fetch price is close to noise.

Which of the three to pick

Ordinary JavaScript rendered pages, moderate volume: ScrapingBee. It is cheaper per rendered page than ZenRows at every comparable tier, it publishes every multiplier including the punishing ones, and 25 concurrent requests on a $19 plan is the most usable entry tier of the three.

Heavily protected targets where bandwidth is predictable: ZenRows. The 25,000 credits per GB residential rate is a different and sometimes much cheaper shape than a 75 credit per request stealth charge, particularly on text heavy pages. Model it against your own page weights rather than assuming.

High volume where you can size the plan accurately: Scrapfly. The credit allowances are the largest in the table and the top tier rate matches the best of the others. Just size up rather than down, because the overage runs three to three and a half times the in plan rate, and confirm the feature multipliers with the estimator before you commit, since they are the one thing you cannot read off the page.

One caveat that applies to all three: ScrapingBee and ZenRows both note that listed prices exclude VAT, so European buyers should add it before comparing against a US quoted alternative.

If the job is rendering your own pages, none of these is the answer

A scraping API exists to get HTML out of a site that is not yours, through defenses built to stop you. If the pages you need are your own application pages, you are paying for proxy rotation, browser fingerprinting and anti-bot bypass that solve a problem you do not have.

The pricing for that job is a different market with different units, and it splits again depending on whether you want session time or a finished file. We compared eight browser and rendering APIs on that basis, including how a one minute billing minimum can make two vendors with the same advertised hourly rate bill twenty five times apart, on our Browserbase pricing comparison. For turning pages into documents specifically, the twelve vendor normalized table on PDF API pricing is the closer read, and screenshot API covers the image case.

The short version

All three sell credits. A JavaScript rendered page costs 5 credits at ScrapingBee and at ZenRows, which makes those two directly comparable, and ScrapingBee is cheaper at every tier that pairs up, from $1.27 against $1.78 per 1,000 pages at the bottom to $0.37 against $0.46 at the top. Protected pages cost 25 credits at both, and ScrapingBee stealth requests cost 75, so a page count without a protection split will not forecast anything. Scrapfly has the cheapest entry credits and the largest allowances but does not publish its feature multipliers, and its overage is more than three times its in plan rate. Check concurrency before price, because 5 concurrent requests is a throughput ceiling no credit discount can fix.