---
title: "Bandwidth billing"
url: https://proxy.wiki/glossary/bandwidth-billing/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Buying guides"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Bandwidth billing

> Charging by gigabyte transferred — the standard model for residential proxies, and easy to underestimate.

**Bandwidth billing charges for data transferred through the proxy rather than for addresses or time.** It is standard for [residential](/glossary/residential-proxy/) and [mobile](/glossary/mobile-proxy/) services.

## What counts as billable traffic

Usually everything: request and response, headers as well as bodies, and typically retries and failed requests too. This is where estimates go wrong. A page whose HTML is 50 KB may transfer well over a megabyte once images, fonts, stylesheets and scripts are included — and a [headless browser](/glossary/headless-browser/) fetches all of them by default.

## Reducing consumption

- Block images, media and fonts when rendering — often the single largest saving.

- Request compression and confirm the server honours it.

- Use an API or JSON endpoint instead of a rendered page where one exists.

- Avoid re-fetching content you already hold.

## Comparing plans honestly

Headline price per gigabyte usually reflects the largest commitment. Compare the tier you will actually buy, and check the minimum spend and whether unused traffic expires.

## What is billable that people do not expect

Metering usually counts bytes crossing the proxy in both directions, not bytes you successfully used. The gap between those two is where unexpected invoices come from.

| Traffic | Commonly billed? |
| --- | --- |
| The response body you wanted | Yes |
| Response headers | Usually |
| Failed and blocked requests | Usually |
| [Challenge pages](/glossary/captcha/) | Usually |
| Redirects you then follow | Yes, both hops |
| Images, fonts and scripts in a rendered page | Yes, every one |
| Retries | Yes, each attempt |

The last three rows explain most surprises. A [headless browser](/glossary/headless-browser/) fetches every asset on the page, so one page view can cost many times what the HTML alone would.

## Reducing consumption

- **Request only what you need.** Block images, fonts and media in a browser context.

- **Accept compression** and make sure it is actually applied.

- **Call the API the page calls,** where one exists. It is usually a fraction of the size.

- **Fail fast.** A short timeout stops a stalled transfer accumulating bytes.

- **Cache what does not change,** so a repeated run does not re-fetch it.

Confirm the definition with the provider before you commit. Ask directly whether failed requests and headers are metered, and get the answer in writing.

## Frequently asked questions

### Does a failed request still cost bandwidth?

Usually yes. Metering normally counts bytes that crossed the proxy, and a blocked or challenged response is still a response. Ask your provider to confirm in writing, because the definition varies.

### Why is my usage far higher than the size of the pages I collect?

Most often because a browser context fetches every asset on the page, or because retries and redirects are counted separately. Blocking images, fonts and media in a rendered page removes a large share of it.

### How do I estimate my usage before committing to a plan?

Measure a representative sample of your own targets rather than the pages you hope to collect. Include failures, retries and redirects, because those are billed too and they are the part people forget.

## Sources

1. [RFC 9110: HTTP Semantics, content coding and message size](https://www.rfc-editor.org/rfc/rfc9110.html)