Web Scraping Pricing: Per GB, Per Page, or Per Request?

Nobody Sells Web Scraping in the Same Unit

Bright Data prices its Web Unlocker per thousand requests. Oxylabs prices Web Unblocker per gigabyte. Firecrawl charges one credit per page. Zyte charges per thousand successful responses, split across five difficulty tiers. Apify bills a compute unit, which is one gigabyte of RAM held for an hour.

Five vendors, five units. Not one of them converts into another without a number you have to go measure yourself, and none of them publishes that number, because it belongs to your traffic rather than to their product.

We read all five pricing pages on September 8, 2026. Here's what they say, and what the arithmetic does to them.

Quick Comparison

Two things jump out of that table.

Zyte's own list spans 124x. Same vendor, same unit, same line on the same invoice: a simple site fetched over HTTP is $0.13 per thousand, an advanced site rendered in a browser is $16.08. Anyone who quotes "per thousand requests" as a comparable number is quoting one end of a range that wide.

And Bright Data switches units halfway through its own catalogue. Web Unlocker is sold per request. Browser API is sold per gigabyte. That isn't sloppiness. It's the tell, and the rest of this post is about what it tells you.

What a Gigabyte Actually Buys

The number that decides every conversion is your average page weight, and the public data on it is brutal.

HTTP Archive's Web Almanac 2025 puts the median mobile home page at 2,559 KB as of the July 2025 crawl, up 8.4% in a year. Break that median page down by content type and you get 911 KB of images, 632 KB of JavaScript, 122 KB of fonts, 77 KB of CSS.

And 22 KB of HTML.

That last number is the one that matters, because the HTML document is usually the only part you parse. On the median page it's 0.86% of the bytes a full browser render pulls down. The other 99% is furniture you paid to move.

Run that through the Oxylabs 8 GB plan at $9.40/GB:

• Fetching HTML only, at 22 KB a page, one gigabyte is roughly 45,000 pages. That's about $0.21 per 1,000 pages.
• Rendering the whole page, at 2,559 KB, one gigabyte is roughly 390 pages. That's about $24 per 1,000 pages.

Same plan. Same advertised price. A 116x spread, decided entirely by a setting in your own code.

Now put Firecrawl next to it. At $83 for 100,000 credits on the annual rate, one credit a page, you pay $0.83 per 1,000 pages whether the page weighs 20 KB or 4 MB. Against HTML-only fetching, the per-gigabyte meter is about four times cheaper. Against full rendering, it's about 29 times more expensive.

The Crossover Sits Near 100 Kilobytes

Do the algebra and the two meters meet at a specific page weight. Firecrawl's $0.00083 a page divided by Oxylabs' $9.40 a gigabyte is 88 KB. Take Firecrawl month to month rather than annually ($99.50 for the same 100,000 credits) and the crossover moves to 106 KB. Below that band, per-gigabyte billing wins. Above it, flat per-page billing wins, and the gap widens fast, because page weight has no ceiling.

Here's the part we like. Oxylabs publishes its own conversion without framing it as one: the Web Unblocker free trial is described as "1GB (up to 10k results)". That's 100 KB per result, landing inside the band we just worked out from two other vendors' price lists. Their own arithmetic assumes you're fetching documents, not rendering galleries.

So if you're on a byte meter and you're driving a browser, the single biggest lever isn't your vendor. It's blocking images and fonts before the page loads, because on the median page that's 1,033 of the 2,559 KB. We'd rather tell you that than pretend the choice of logo on the invoice is what decides the bill.

Two honest caveats. These are median figures across the whole web, and your targets are not the whole web (retail and travel pages run heavier, JSON endpoints far lighter). And a rendered page with media blocked can land well under the median, which moves the crossover in your favor without changing anything on the pricing page. The same arithmetic decides when an LLM extraction step stops paying for itself: the unit price is never the interesting number, the price per record you kept is.

What Counts as Billable Is a Second Axis

Unit is one question. What triggers the meter is a different one, and it's easier to miss.

Bright Data advertises "pay only for success" on Web Unlocker. Zyte prices "per 1,000 successful responses". Firecrawl spends a credit per API request, by endpoint. On a per-gigabyte meter there is no success condition at all: the bytes moved, so you're billed, and a challenge page you throw away is a page you bought.

That matters more than it sounds, because a challenge or an interstitial usually arrives with HTTP 200 attached. If your definition of success is the status code, your retry logic and your invoice will disagree with your dataset. We wrote about that split in Validate Rules Now Decide What Counts as Success, and it's the same fault line that turns a partial block into a silent hole in a time series.

Who Should Buy Which Unit

Buy per gigabyte if you fetch documents rather than render them, and your targets are text: search results, JSON endpoints, listing pages, sitemaps. At 20 to 50 KB a page, byte pricing is the cheapest thing on the market and nothing else is close.

Buy per page or per request if you render, if your targets are media-heavy, or if you simply can't predict page weight across a long tail of sites. You're paying a premium at the small end to buy a ceiling at the large end, and on a rendering workload that ceiling is worth a lot.

Buy per tier, as Zyte sells it, if your target mix is stable and you know which tier each site falls into. The model is honest about the thing everyone else averages away, which is that hard sites cost more to collect. It's a poor fit when your target list churns weekly.

Buy compute units if you run long crawls with your own code on the platform. That meter bills the machine, not the data, so it rewards a fast parser and punishes a slow one. It's the only model on this list where optimizing your code shows up directly on the invoice.

None of these units is a trick. Each one is a bet about what typical traffic looks like, made by a vendor who knows their own customer base. The mistake isn't picking the wrong unit. It's comparing two quotes that were never in the same unit and calling the cheaper number a decision.

The Price Rises Whether or Not Anyone Raises It

Before you take a quote from anyone, including us, go measure two numbers from a week of your own traffic: bytes per fetch, and the share of fetches that returned something you actually kept. Every quote in this post converts cleanly once you have those two, and none of them converts without them.

Then watch what happens next year. The median home page grew 7.8% in twelve months, and the pressure is all in one direction. If your bill is denominated in bytes, that's an annual price increase nobody has to announce, on a line item nobody negotiated.

At FourA we hand back what each call cost in the response itself, so the conversion is something you read as you go rather than reconstruct from an invoice at the end of the month. That won't tell you which unit to buy. It will tell you what you're actually spending per page you kept, which is the number the whole argument turns on.