Rex says
The fast lane for the math you almost remember from school. Type the numbers, get the answer, move on with your day.
Try a scenario
Click to load — tweak from there.Inputs
Result
Required bandwidth
3,250
In Gbps
3.25
Max users your existing link supports
154
Utilization of existing link at target load
325.0%
Psst — share this and help Rex grow
One click, a permanent link with your numbers baked in.
How to use this
- 1Enter peak concurrent users.
- 2Enter bandwidth per user (Mbps).
- 3Enter headroom / burst margin (%).
- 4Enter existing link capacity (optional) (Mbps).
- 5Read your required bandwidth on the right — it updates as you type.
- 6Hit Share to keep the scenario or send it to someone.
About this calculator
Sizing bandwidth for concurrent users is a capacity-planning problem, not just multiplication — you need per-user bandwidth, expected concurrency (not total user count), and a safety headroom margin to absorb bursts and avoid running at 100% utilization, which causes latency spikes and packet loss well before you technically hit the ceiling. This calculator multiplies per-user bandwidth by concurrent users, adds your headroom percentage, and reports the required link speed in Mbps and Gbps. It also reports the theoretical max concurrent users your current link could support, so you can check existing infrastructure against a growth target. A commonly cited network engineering rule of thumb is to provision for no more than 70-80% sustained utilization on any link, since queuing delay rises sharply as utilization approaches 100% — this tool bakes that in as the default headroom.
Worked example
Using the values the calculator loads with:
Inputs
- Peak concurrent users: 500
- Bandwidth per user: 5 Mbps
- Headroom / burst margin: 30 %
- Existing link capacity (optional): 1000 Mbps
Results
- Required bandwidth: 3,250
- In Gbps: 3.25
- Max users your existing link supports: 154
- Utilization of existing link at target load: 325.0%
What each field means
Inputs
- Peak concurrent users
- The peak concurrent users used in the calculation. Starts at 500 so you have a working example on load.
- Bandwidth per user (Mbps)
- The bandwidth per user used in the calculation, measured in Mbps. Starts at 5 Mbps so you have a working example on load.
- Headroom / burst margin (%)
- The headroom / burst margin used in the calculation, measured in %. Starts at 30 % so you have a working example on load. Accepted range: 0–200 %.
- Existing link capacity (optional) (Mbps)
- The existing link capacity (optional) used in the calculation, measured in Mbps. Starts at 1000 Mbps so you have a working example on load.
Results
- Required bandwidth
- Returned as a whole number and shown as the headline result. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- In Gbps
- Returned as a decimal number. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- Max users your existing link supports
- Returned as a whole number. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- Utilization of existing link at target load
- Returned as a percentage. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
FAQ
What per-user bandwidth should I assume?
It depends entirely on workload: basic web browsing needs roughly 1-2 Mbps per user, SD video conferencing 2-4 Mbps, HD video conferencing 4-8 Mbps, and 4K video streaming 25 Mbps or more. Measure real per-user usage from existing traffic logs if you have them; guessing from generic averages is the most common source of under- or over-provisioning.
Should I size for concurrent users or total registered users?
Always concurrent (simultaneously active) users, never total registered accounts — the two can differ by 5-20x depending on the product. If you don't have real concurrency data yet, a common starting estimate for consumer apps is 10-20% of daily active users online at the peak hour, but validate this against real traffic as soon as you have it.
Why not just provision for 100% of link capacity?
Network queuing theory shows latency and packet loss rise non-linearly as utilization approaches 100%, because burst traffic has no slack to absorb — a link running at 95% average utilization will see far worse latency spikes during traffic bursts than one running at 70%. The headroom percentage in this calculator exists specifically to keep sustained utilization in the safe range.
Accuracy and limitations
- Results are rounded for display; the underlying calculation keeps full precision.
- Very large or very small inputs may hit floating-point limits in the browser.
- Inputs outside the accepted range are clamped rather than rejected.
Related tools
Data Transfer Time Calculator
Estimate how long a data transfer will actually take at a given bandwidth.
Video Streaming Bitrate & Storage Calculator
Convert resolution and bitrate into file size, storage cost, and bandwidth needs.
Cloud Egress Bandwidth Cost Calculator
Find out what shipping data out of the cloud actually costs you.
Cite this calculator
Writing about this topic? Grab a citation — every link helps keep these tools free.
RevenueLab. (2026). Bandwidth Needed for N Concurrent Users. Retrieved from https://www.revenuelab.fyi/toolbox/bandwidth-for-n-users
<p>Source: <a href="https://www.revenuelab.fyi/toolbox/bandwidth-for-n-users" target="_blank" rel="noopener">Bandwidth Needed for N Concurrent Users — RevenueLab</a> (2026).</p>
Source: [Bandwidth Needed for N Concurrent Users — RevenueLab](https://www.revenuelab.fyi/toolbox/bandwidth-for-n-users) (2026).