“Unlimited bandwidth” shows up on nearly every hosting plan’s marketing page, which makes it a genuinely unhelpful number for actually comparing hosts, but understanding roughly how much bandwidth a real site uses is still worth knowing, both to sanity-check a plan that isn’t advertised as unlimited and to understand what’s actually driving a hosting bill on usage-based plans.
The Actual Calculation
Bandwidth usage comes down to three numbers multiplied together: average page size, monthly visitors, and average pages viewed per visit. A site with a 2MB average page size (roughly typical for a modern site with images, a bit of JavaScript, and normal styling), 10,000 monthly visitors, and 3 pages viewed per visit works out to 2MB times 10,000 times 3, which is 60GB a month, before accounting for anything beyond the basic page-view calculation.
What the Basic Formula Leaves Out
That 60GB is a theoretical floor, not a realistic estimate, real usage runs meaningfully higher. Search engine crawlers, malicious bots, failed or partial page loads, users hitting refresh, and plain HTTP overhead all add real bandwidth that never shows up in a simple “visitors times page size” calculation. A reasonable safety buffer is 30-50% on top of the basic number, and for anything with unpredictable spikes, a seasonal sale, a piece of content that goes viral, a marketing campaign driving a sudden traffic surge, budgeting toward the higher end of that range is the safer call.
Where Your Actual Traffic Numbers Come From
Rather than estimating in the abstract, pulling real numbers from your own site’s analytics is far more useful than guessing: your hosting control panel typically shows actual visitor counts and bandwidth already consumed, and any analytics tool gives you real average pages-per-visit data specific to how people actually use your site, which varies a lot by site type. A blog where people read one article and leave looks completely different from an e-commerce store where visitors browse multiple product pages, and using your own real numbers beats applying a generic industry average to a site that might not resemble that average at all.
What Actually Drives Bandwidth Up
Unoptimized images are the single biggest lever most sites have never pulled: a page full of full-resolution photos straight from a camera or phone can easily run 5-10x heavier than the same page with properly compressed, appropriately-sized images, and that difference multiplies across every single page view. Video embedded directly rather than linked from YouTube or Vimeo, large uncompressed downloads, and heavy, unoptimized JavaScript or font files are the other usual culprits. Before assuming a hosting plan’s bandwidth allocation is the problem, checking whether the site’s own pages are needlessly heavy is often the faster, cheaper fix, since it reduces bandwidth use regardless of which host or plan you’re on.
What “Unlimited” Actually Means in Practice
Plans advertised as unlimited bandwidth almost always carry a fair-use policy in the terms of service, a practical ceiling that isn’t advertised as a specific number but exists nonetheless, kicking in only for genuinely unusual usage patterns most normal sites never approach. For the vast majority of sites, that distinction is academic; a typical blog, portfolio, or small business site running the calculation above rarely gets anywhere near where a fair-use policy would actually trigger. It matters more for a site expecting a real spike, a product launch, a piece of content with a real shot at going viral, where it’s worth confirming directly with a host what actually happens if usage spikes well beyond typical, rather than assuming “unlimited” has no practical ceiling at all.
The Practical Takeaway
Run the calculation with your own real numbers, average page size (checked directly, not assumed), actual monthly visitors from analytics, real pages-per-visit, add a reasonable buffer, and compare that estimate against what a plan actually provides. For most small and mid-sized sites, that number lands comfortably within any reasonable shared hosting plan’s real capacity, unlimited or not; the exercise is more useful as a sanity check and a prompt to notice unnecessarily heavy pages than as a genuine constraint most sites will ever bump into.