Web Scraping Cost Per Million Requests: The 2026 Breakdown

Ask a proxy vendor what scraping costs and you'll get a price per gigabyte. Ask a scraping API and you'll get a price per credit, with an asterisk explaining that JavaScript rendering costs ten credits, not one. Ask your own engineers and you'll get a shrug, because last month the pipeline ran fine and this month the target rolled out a new bot-detection vendor and half the fleet is staring at CAPTCHAs.

None of those answers is the one you need. The only number that lets you compare a DIY crawler against a scraping API against an antidetect-browser fleet is web scraping cost per million requests — and specifically per million successful requests, because a blocked request costs you money and returns nothing.

This guide builds that number from the ground up: the four line items in every scraping budget, real 2026 price ranges, the block-rate multiplier that quietly doubles or triples your effective spend, and a worked example pricing a 10-million-request monthly job. I'll also be honest about where an antidetect browser like Dual Login belongs in this equation — and where it doesn't.

Why "per million requests" is the only honest unit

Every vendor in this industry prices in a different unit on purpose. Proxies are sold per gigabyte or per IP. Scraping APIs are sold per credit. Headless-browser clouds are sold per browser-hour. CAPTCHA solvers are sold per thousand solves. Antidetect browsers are sold per profile or per seat. If you try to compare sticker prices, you're comparing a currency you can't spend.

Your job, on the other hand, is measured in pages. "We need the price and stock level of 400,000 SKUs, refreshed daily" is 12 million requests a month before a single retry. So the conversion every budget has to make is: take each line item, figure out how many requests it actually buys you, and divide.

There's one more wrinkle, and it's the one that sinks most estimates. You don't pay for successful requests — you pay for attempts. If your setup gets blocked 30% of the time, every successful page cost you roughly 1.43 attempts (plus the retry logic, the backoff delay, and the burned IP). The formula that actually predicts your bill is:

Effective cost per million = (proxy spend + compute spend + tooling spend per million attempts) ÷ success rate

Hold onto that. Everything below is just filling in the variables.

The four line items in every scraping budget

1. Proxies and bandwidth — usually the biggest number

Proxy pricing in 2026 has settled into fairly stable bands:

• Datacenter proxies: $0.50–$2.00 per GB, or $1–$3 per dedicated IP per month. Cheap, fast, and increasingly useless against anything running serious bot protection, because datacenter ASN ranges are the first thing every anti-bot vendor scores.
• ISP (static residential) proxies: $2–$5 per IP per month. Datacenter speed with residential reputation. Great for long-lived sessions; expensive if you need thousands of distinct IPs.
• Rotating residential proxies: $2–$8 per GB depending on volume commitments. The workhorse for protected targets.
• Mobile proxies: $10–$30 per GB or $50–$200 per port per month. Reserved for the most hostile targets, because carrier-grade NAT gives mobile IPs near-immunity to IP bans.

Per-GB pricing means your real cost depends entirely on how heavy each request is, and the spread is enormous:

• A JSON API response: 5–50 KB
• A raw HTML page (no subresources): 100–500 KB
• A full browser render with images, fonts, scripts and trackers: 1–3 MB

Do the multiplication and the stakes get obvious. One million raw HTML fetches at 300 KB is about 300 GB — roughly $1,200 on mid-tier residential bandwidth at $4/GB. One million full browser renders at 2 MB is 2 TB — about $8,000 on the same proxies. Same target, same data extracted, 6–7× the bandwidth bill, purely because nobody blocked the images. We'll come back to that, because it's the cheapest optimization in this whole article.

2. Compute — cheap for HTTP, real money for browsers

Plain HTTP scraping is computationally almost free. A $20/month VPS running an async client comfortably pushes millions of requests a day; your compute cost per million rounds to pocket change. This is why commodity crawling — the kind described in the Wikipedia overview of web scraping — has always been dominated by raw HTTP clients.

Headless browsers are a different animal. Chromium's multi-process architecture spins up separate processes per site and per renderer, which is wonderful for stability and terrible for density. Realistic planning numbers in 2026:

• 300–500 MB of RAM per browser context, more on script-heavy pages
• Roughly one concurrent rendering tab per CPU core if you want stable latency
• 4–8 seconds wall-clock per fully rendered page on a protected site

Run the math: at 6 seconds per page, one concurrent tab does about 600 pages an hour. To render a million pages in a day you need around 70 concurrent tabs, which means a 32–64 vCPU footprint — call it $150–$400 a month across a couple of dedicated servers, or noticeably more on hourly cloud instances. Amortized, browser compute lands around $5–$15 per million rendered pages if your utilization is good, and several times that if your fleet sits idle between bursts.

3. Anti-bot losses — the multiplier nobody budgets

This is the line item that doesn't appear on any invoice, which is exactly why it wrecks estimates. Modern bot detection stacks score you on at least four layers:

1. IP reputation — ASN type, abuse history, request density per subnet
2. TLS and HTTP/2 fingerprints — your client library's handshake is a signature; a Python client claiming to be Chrome fails this instantly
3. Browser fingerprint — canvas, WebGL, fonts, screen metrics, timezone-vs-IP coherence; if you're new to this layer, start with our beginner's guide to browser fingerprinting
4. Behavior — mouse entropy, timing, navigation patterns, and whether navigator.webdriver betrays an automation framework

Each failed layer either blocks you outright or feeds you a CAPTCHA. CAPTCHA solving runs $0.50–$3.00 per thousand solves for standard challenges and several times that for the hard ones — and a solve adds 10–30 seconds of latency, which drags your compute utilization down too.

The block rate itself is the multiplier. At a 10% block rate your effective cost is sticker ÷ 0.9 — an 11% tax, tolerable. At 40%, everything costs 67% more. At 70% — common when a fleet of identical fingerprints hits a protected target from datacenter IPs — you're paying more than three times your projected number and probably burning proxy pools that then need replacing. If you want to see what detectors see, the EFF's Cover Your Tracks tool is a sobering two-minute demo of how identifiable a default automation setup is.

4. Engineering time — the invisible majority

On small and mid-size operations, salaries dwarf infrastructure. Selectors break. Targets redesign. Anti-bot vendors ship updates on their schedule, not yours. A scraper that needs four hours of maintenance a week costs $1,500–$3,000 a month in developer time at ordinary rates — often more than the proxies and servers combined. Any architecture decision that trades a little infrastructure money for a lot less breakage is usually the right trade, and that context matters when we get to build-vs-buy below.

Benchmark table: what a million requests actually costs in 2026

Ranges, not gospel — your targets, page weights and success rates move every number. But these bands are what real workloads land in:

*Success rate against moderately protected targets; unprotected sites succeed at ~99% for every method.

Two things jump out of that table. First, the spread between "full render" and "assets blocked" on the same architecture is 4–5× — bandwidth discipline is worth more than any proxy discount you'll ever negotiate. Second, the antidetect row isn't playing the same game as the others, and that's the point: it wins by needing fewer requests, not by making each request cheaper. More on that in a minute.

The block-rate multiplier: where budgets actually die

Let's make the multiplier concrete, because percentages hide the pain.

Say you've priced a workload at $800 per million attempts — residential bandwidth plus a modest browser fleet. You assumed a 95% success rate, so you budgeted $842 per million successful pages. Reality arrives: the target runs a top-tier anti-bot vendor, your fleet's fingerprints are all identical Puppeteer defaults, and your true success rate is 55%.

Now every million successful pages costs $800 ÷ 0.55 = $1,454 — before counting the CAPTCHA solves on the borderline requests, the longer wall-clock time (idle browsers still bill), and the proxy pool churn as IPs get flagged. Your "$842" line item is really $1,700+. Nothing on any invoice changed; your assumptions did.

This is why fingerprint work has direct ROI in a scraping budget, which surprises people who file it under paranoia. Every detection layer you pass moves the denominator. Rotating a user-agent string does approximately nothing — detectors cross-check dozens of signals against each other, and an inconsistent set (a Windows UA with Linux fonts, a UTC-8 timezone on a German IP) scores worse than an honest one. If you want to understand what actually moves the number, our practical guide to changing your browser fingerprint walks through which signals matter and why naive spoofing backfires.

It's also why a VPN does nothing for scraping economics: it changes exactly one signal (your IP) and leaves every fingerprint intact. If that distinction is fuzzy, antidetect browser vs VPN covers it properly.

Cutting bandwidth: the cheapest optimization almost nobody ships

If you take one tactical thing from this article, take this: audit what each request downloads before you negotiate a single proxy price.

• Block subresources you don't parse. Images, fonts, media, analytics and ad scripts are typically 60–85% of a page's weight. Every serious browser-automation stack can abort those requests before they leave the machine. On a per-GB residential plan, this one interception rule can cut your proxy bill by three quarters.
• Hunt for the JSON. Most modern sites hydrate their pages from internal JSON endpoints. Open devtools, watch the network tab, and you'll often find the exact data you're rendering a 2 MB page to extract — served as a 20 KB response. That's a 100× bandwidth reduction and it usually parses more reliably than HTML.
• Use conditional requests where the target supports them. ETag and Last-Modified headers exist precisely so a client can ask "has this changed?" for the cost of a 304 instead of a full body. MDN's HTTP caching documentation is the canonical reference. For daily refresh jobs where most pages don't change, this quietly halves bandwidth.
• Reuse connections. Keep-alive and HTTP/2 multiplexing don't just cut latency; TLS handshakes cost bytes too, and on millions of requests the handshake overhead alone is measurable gigabytes.

None of this is glamorous. All of it compounds. A team that blocks assets, hits JSON endpoints and sends conditional requests can run the same logical workload for a tenth of the naive bandwidth bill.

Session reuse: fewer requests beat cheaper requests

Here's the shift in thinking that separates expensive scraping operations from efficient ones: the cheapest request is the one you never send.

Consider any target that lives behind a login — seller dashboards, ad platforms, marketplace back-offices, analytics portals. A stateless scraper treats every visit as a stranger: load the login page, submit credentials, survive the CAPTCHA or 2FA challenge that fresh logins increasingly trigger, collect the session cookie, then fetch the one page it came for. That's 5–15 requests, several seconds, and a meaningful ban-risk event — per visit. Worse, repeated fresh logins from rotating IPs are themselves a classic fraud signal, so the more you scrape this way, the more hostile the target becomes.

A persistent browser profile inverts all of it. The session cookie from Monday is still there on Tuesday. Visit two is one request: the page you want. The login dance happens once a month instead of a thousand times a day, your request volume for the same data drops by 80–90%, and — the part that compounds — your accounts age. An account with a stable fingerprint, a consistent residential IP and a continuous session history accumulates trust; anti-fraud systems treat it progressively more gently, which pushes your success rate up while everyone else's decays.

This is precisely the workload antidetect browsers were built for. Dual Login runs each profile as a real, separate Chromium process with its own data directory — cookies, localStorage and IndexedDB persist across launches exactly like a real user's machine — with a unique, internally consistent fingerprint applied natively inside the engine rather than injected as detectable JavaScript. Pair each profile with a sticky residential IP and you've built a fleet of boring, trustworthy, long-lived browser identities. The residential proxies playbook covers the pairing strategy in detail.

Where an antidetect browser fits in the cost equation — and where it doesn't

Let me be straight about this, because vendors in this space routinely oversell.

Where it's the wrong tool: commodity crawling. If you need 100 million product pages from lightly protected sites, an async HTTP client with datacenter proxies wins on cost by two orders of magnitude, and nothing an antidetect browser does changes that. Full browsers are heavy; you use them when the target forces you to.

Where it wins on pure economics:

• Account-bound, high-value data. Dashboards, portals and platforms where each request is worth dollars, not fractions of a cent, and where a banned account costs you far more than any proxy bill. Here the success-rate denominator dominates the equation, and persistent, consistent identities are what move it.
• Targets that fingerprint aggressively. When the block rate on a vanilla headless fleet crosses ~40–50%, the effective-cost math flips: paying for proper fingerprint isolation becomes cheaper than paying the block-rate tax, because native fingerprinting (canvas, WebGL, fonts, timezone, screen — all coherent with each other and with the proxy's geography) is the difference between a 55% and a 95% success rate.
• Many concurrent identities on one machine. Each Dual Login profile is an isolated OS process with its own data dir, so dozens of long-lived sessions coexist on a single workstation without cross-contamination — no per-browser-hour cloud bill.
• Automation without the webdriver tell. Dual Login's automation API drives tabs over raw CDP without the flags and JavaScript artifacts that betray standard frameworks, so your automated sessions inherit the profile's trust instead of spending it.

On pricing structure: antidetect browsers charge per profile or per seat, not per request. That flips the marginal math — once you're paying for 100 profiles, the incremental cost of another thousand requests through them is just bandwidth. For steady, account-bound workloads this makes monthly costs predictable in a way per-credit APIs never are. If budget is the binding constraint, our buyer's guide for small teams breaks down what the per-profile tiers actually buy you.

A worked example: pricing a 10M-request/month job

Theory is nice; budgets are numbers. Here's a realistic mixed workload — say, an e-commerce intelligence operation — priced the way I'd price it today.

Workload: 10 million requests a month, split three ways:

Segment A — 8M requests: public product data from lightly protected sites. JSON endpoints found via devtools, ~30 KB average response. Plain HTTP client, datacenter proxies at $1/GB. Bandwidth: 240 GB → $240. Compute: one $40 VPS. Success rate ~97%, retries negligible. Segment cost: ~$290, or about $36 per million.

Segment B — 1.5M requests: protected listing pages needing JS rendering. Headless fleet with images/fonts/analytics blocked, ~350 KB per render. Residential bandwidth at $4/GB: 525 GB → $2,100. Compute: ~$120 amortized. Success rate 88% after fingerprint hygiene → effective ~$2,520. Segment cost: ~$2,520, or about $1,680 per million. (Rendered without asset blocking, this same segment would have cost over $9,000 — that's the bandwidth section of this article paying for itself.)

Segment C — 0.5M requests: logged-in seller/portal data across ~120 accounts. Dual Login profiles with sticky residential IPs. Because sessions persist, there's no login overhead in the request count — 500K requests really means 500K data pages. Bandwidth ~150 GB residential → $600. Antidetect subscription tier + one workstation → ~$150. Success rate with aged accounts and consistent fingerprints: 96%+. Segment cost: ~$780, or about $1,560 per million — for the highest-value, hardest-to-get data in the entire operation. A stateless approach to this segment would have added ~3M login-flow requests, tripled the CAPTCHA spend, and burned accounts monthly.

Total: roughly $3,600/month for 10M successful requests — a blended ~$360 per million — with the expensive segments costing what they cost because of what they return, not because of waste. The point of the exercise isn't these exact numbers; it's the method. Segment the workload, price each segment honestly with its own success rate, and put the heavyweight tooling only where the target demands it.

Ten levers that cut your cost per million requests

1. Block images, fonts and analytics on every rendered page. 60–85% bandwidth reduction, one interception rule.
2. Find the JSON endpoints behind the HTML. Often a 50–100× lighter response that parses more reliably.
3. Segment your targets by protection level and only pay for residential IPs and browser rendering where they're actually required.
4. Persist sessions on login-bound targets instead of re-authenticating — fewer requests, fewer CAPTCHAs, older and more trusted accounts.
5. Fix fingerprint coherence before buying more proxies. A 30-point success-rate improvement beats a 30% proxy discount, and it's the block rate that usually has the most headroom.
6. Use conditional requests (ETag/If-Modified-Since) on refresh jobs so unchanged pages cost a 304, not a full body.
7. Match IP geography to fingerprint geography. Timezone, language and locale that contradict the exit IP raise block rates all by themselves.
8. Batch and schedule for utilization. Idle browser fleets bill anyway; a fleet at 80% utilization halves your effective compute cost versus one at 40%.
9. Rate-limit like a human, not like a benchmark. Slower per-identity request rates cost wall-clock time but protect the success rate that dominates the equation.
10. Measure cost per successful request weekly. It's the only metric that catches a rising block rate before the monthly invoice does.

FAQ

What is a realistic web scraping cost per million requests in 2026?

Anywhere from about $15 to over $10,000, which is why the question needs qualifying. Plain HTTP against unprotected sites with datacenter proxies: $15–$150 per million. Residential proxies push that to $180–$1,300. Full browser rendering on residential bandwidth runs $500–$2,400 with asset blocking and $2,300–$10,000 without. Scraping APIs with JS rendering typically land at $1,000–$4,000 per million. The dominant variables are page weight, proxy tier, and — above all — your success rate.

Are residential proxies always necessary?

No, and defaulting to them is a common budget leak. Unprotected and lightly protected targets work fine on datacenter IPs at a tenth of the price. Reserve residential (or mobile) bandwidth for targets that actually score IP reputation, and segment your workload so the cheap traffic rides cheap IPs.

How much does using a headless browser add to the cost?

Two costs stack: compute (roughly $5–$15 per million pages at good utilization, given ~300–500 MB RAM and about one rendering tab per core) and bandwidth (a rendered page pulls 1–3 MB versus 100–500 KB for raw HTML — a 4–6× multiplier on per-GB proxy plans unless you block subresources). Only render where the target genuinely requires JavaScript execution.

How do block rates change the effective cost?

Divide your sticker cost by your success rate. A 10% block rate is an 11% surcharge; a 50% block rate doubles every line item and adds CAPTCHA and retry costs on top. This is why fingerprint consistency and IP quality are economic decisions, not just stealth decisions — they move the denominator that every other cost is divided by.

When is an antidetect browser cheaper than a scraping API?

When the work is account-bound and session persistence matters: seller dashboards, ad platforms, marketplace portals. APIs price per request and start every call as a stranger; an antidetect browser like Dual Login prices per profile, keeps sessions alive between runs, and lets accounts build trust — so the same data costs fewer requests at a higher success rate. For anonymous commodity crawling at massive volume, the API or a DIY HTTP fleet usually wins instead.

How do I estimate bandwidth per request before committing to a proxy plan?

Sample it. Fetch 100 representative pages through your actual pipeline configuration (with your real blocking rules) and measure transferred bytes — browser devtools or your proxy dashboard both report it. Multiply the average by your monthly request volume, add 10–20% for retries, and you have a defensible GB figure to negotiate with instead of a guess.

The bottom line

Web scraping cost per million requests isn't one number — it's a formula with four inputs, and the input teams consistently get wrong isn't the proxy price on the invoice, it's the success rate hiding in the denominator. Price your attempts honestly, segment your targets so heavyweight tooling only touches the pages that need it, cut bandwidth before you cut proxy corners, and treat session persistence and fingerprint coherence as the cost levers they are.

For the account-bound, high-value end of your workload — the segment where blocks and bans are most expensive — isolated, persistent browser profiles are usually the cheapest reliable option per successful request. Dual Login gives each identity its own real Chromium process, a natively applied and internally consistent fingerprint, per-profile proxies, and an automation API that doesn't announce itself. If you're pricing a scraping operation this quarter, put it through a proper trial on your hardest target and measure what happens to your success rate. The denominator is where the money is.