:format(webp))
Monthly bandwidth need = requests per day × average response size × days per month, adjusted for retries and failed requests. The average response size is the part most people guess wrong — a JSON API call might be 20KB, a full rendered page can be 1-3MB, and an image-heavy page can run 3-5MB or more. Get that number right for your actual task and the rest is simple multiplication. Every figure below is a typical range, not a guaranteed number — actual page weight varies by site, so treat this as a starting estimate to test and refine, not a fixed calculation.
The basic formula
Monthly GB = (requests per day × average response size in MB × days active per month) / 1000The formula itself is simple. The part worth getting right is the average response size, because it varies enormously by what you're actually requesting.
Bandwidth by request type
Request type | Typical size | Notes |
|---|---|---|
JSON/API call | 5-100 KB | Structured data responses, no rendering |
Plain HTML page (text-focused) | 200 KB - 1 MB | News articles, product listings, search results pages |
Full rendered page (headless browser, all assets) | 1-3 MB | Includes CSS, JS, images the browser loads by default |
Image-heavy page (e-commerce, social media) | 2-5 MB | Product galleries, social feeds with media |
Video/streaming content | 40-200+ MB per hour | Varies heavily by quality setting |
The gap between a raw JSON call and a fully rendered image-heavy page is the single biggest variable in any sizing estimate — confirming which one your actual workflow makes is worth doing before estimating anything else.
A note on these numbers: the ranges above are typical, not fixed — actual size depends on the specific site, how many images or scripts it loads, and how your scraper is configured. Two "image-heavy pages" from two different sites can differ by 2x or more. Use this table to get in the right order of magnitude, then confirm against your real target with a small test run before buying volume based on the estimate alone.
Worked examples
Price monitoring via API, 500 products, checked twice daily: 500 products × 2 checks × 30 days = 30,000 requests/month. At 50KB per API response: 30,000 × 0.05MB = 1,500MB ≈ 1.5 GB/month.
SERP rank tracking, 200 keywords, full rendered pages, checked daily: 200 keywords × 30 days = 6,000 requests/month. At 2MB per rendered page: 6,000 × 2MB = 12,000MB ≈ 12 GB/month.
Social media account monitoring, image-heavy feeds, 50 accounts checked 4x daily: 50 accounts × 4 checks × 30 days = 6,000 requests/month. At 3.5MB per image-heavy page: 6,000 × 3.5MB = 21,000MB ≈ 21 GB/month.
These three examples span a 14x range in monthly bandwidth from a similar request count, purely because of what's actually being loaded on each request. Treat the totals as illustrative math, not a prediction of your exact bill — the real number depends on your actual target sites, which is why testing on a small allocation before buying volume matters more than getting the estimate perfect.
What the basic formula misses
Retries and failures. Even a well-run residential network fails on a small percentage of requests, and retries consume bandwidth on the failed attempt too. Padding an estimate by 10-15% for retries is more realistic than assuming every request succeeds on the first try.
Growth. A workflow that starts at 50 tracked items rarely stays at 50 — sizing for current volume only means re-checking your estimate every time the workflow scales, rather than building in headroom from the start.
Blockable bandwidth waste. A headless browser loading full page assets by default pulls significantly more data than the same request with images and unnecessary scripts blocked. If you only need the text or data on a page, disabling image loading in your scraping setup can cut bandwidth use substantially without losing anything you actually need.
Why the buying model matters as much as the estimate
A sizing estimate is still an estimate — actual usage typically lands somewhere in a range, not on an exact number. That's the practical case for pay-as-you-go pricing with no expiration: buying 1 GB to validate your actual per-request size against real targets, then scaling based on measured usage rather than a projected one, removes most of the risk of either underbuying (running out mid-task) or overbuying (paying for a monthly allotment that expires unused before you get to it).
FAQ
How do I estimate bandwidth for web scraping? Multiply your expected daily request count by the average response size for your specific request type (API call, HTML page, or fully rendered page), then by the number of days you'll run the task. Add 10-15% for retries.
Why do image-heavy pages use so much more bandwidth than API calls? An API call returns only structured data, often under 100KB. A fully rendered page with images, CSS, and scripts can run 2-5MB — the images and page assets, not the core content, account for most of the difference.
Should I buy more bandwidth than I estimate I need? With a pay-as-you-go, non-expiring model, there's little downside to buying a bit more than your estimate as a buffer, since unused bandwidth isn't lost. With a monthly-reset plan, overbuying means paying for GB you may not use before it resets.
How can I reduce bandwidth usage without changing what data I collect? If a headless browser is loading full page assets by default, disabling image and unnecessary script loading when you only need text or structured data can meaningfully cut bandwidth without losing the information you're actually after.