Bandwidth Calculator — How Much Capacity Does Your Link Need?

Background.

This bandwidth calculator answers the capacity-planning question, not the transfer question. You tell it how many sessions are live at the same moment and what bit rate each one needs; it returns the link capacity that demand requires once protocol overhead and engineering headroom are added, what percentage of your existing circuit that consumes, and how many concurrent users the circuit you already own will actually carry. If what you want instead is how long a single file takes to move at a given speed, that is a different calculation and Quanta has a separate download time calculator for it.

Two unit conventions decide whether a bandwidth answer is right or off by a factor of eight, and this page states both explicitly. First, everything here is in bits, not bytes. A 5 Mbps video stream moves five million bits per second, which is 625,000 bytes per second — divide by eight, never assume. Rates are quoted in bits by every network vendor and every ISP; file sizes are quoted in bytes by every operating system. Second, every prefix on this page is decimal. One megabit per second is 10⁶ bit/s and one gigabit per second is 10⁹ bit/s. NIST's own reference on binary multiples records the split plainly: telecommunications engineers use the decimal megabit per second, while memory manufacturers use 2²⁰ for the megabyte. Binary prefixes — mebibit, gibibyte — are never used for rates here, and the one byte figure the page returns, peak-hour volume, is likewise decimal, with 1 GB = 10⁹ bytes.

The word bandwidth is itself imprecise, and RFC 5136 says so in as many words: literature overloads it to mean what the RFC calls capacity, and the RFC defines IP-layer link capacity as the maximum number of IP-layer bits that can be transmitted and correctly received over a link during an interval, divided by that interval. Everything this calculator returns is a capacity in exactly that sense. Ask three people the bandwidth of an 802.11b link and you get 11 Mbit/s from the network engineer, 25 MHz from the electrical engineer and an honest 8 Mbit/s from the user watching a file copy — which is the whole reason a page like this must say which of the three it means.

The overhead field is where most bandwidth estimates quietly go wrong, and it is the one number here that cannot be derived to a single correct value — so the page derives its floor and exposes the rest. RFC 791 fixes the minimum IPv4 header at five 32-bit words, twenty octets. RFC 9293 fixes the minimum TCP header at another twenty. RFC 894 caps an IP datagram over Ethernet at 1,500 octets. At a full MTU that leaves 1,460 octets of payload inside 1,500 octets on the wire, a layer-3 framing tax of 2.74% before a single Ethernet preamble, TLS record, acknowledgement or retransmission is counted. Real overhead on encrypted traffic across a lossy access link lands well above that, which is why the default here is 10% and the field is editable rather than baked in. Engineering headroom is a design choice with no RFC behind it at all — 20% is a common access-link convention, and you should change it to whatever your own change-control process demands.

The user ceiling is the output most people actually need. Buying capacity is a procurement decision with a lead time; discovering three months later that the circuit tops out at seventy-five concurrent streams rather than the hundred you promised is the failure mode this page exists to prevent. That figure is deliberately floored to a whole session, because a link that supports 75.76 users supports 75 users.

Below the widget you will find the full arithmetic with every constant sourced, a worked example computed by hand and reproduced exactly by the code, an explanation of why concurrency and headcount are different numbers, guidance on where per-user bitrates actually come from, and a plain account of what a capacity model like this one cannot tell you — jitter, latency, queueing behaviour under burst, and everything else that makes a link that passes this test still feel slow.

What is bandwidth calculator?

Bandwidth, in the sense used on this page, is link capacity: the maximum rate at which bits can cross a link and be correctly received, measured in bits per second. RFC 5136 formalises it as the maximum number of IP-layer bits transmitted from a source and correctly received by a destination over a link during an interval, divided by the length of that interval. It is a rate, not a quantity — capacity is what the pipe can carry per second, volume is how much water came out. A bandwidth calculation for a network with many simultaneous users has three parts. The first is aggregate demand: how many sessions are concurrent, multiplied by what each one sustains. The second is overhead: the fraction of every bit on the wire that is header, framing, acknowledgement or retransmission rather than payload, which for TCP over IPv4 over Ethernet at a full MTU has a floor of 2.74% at layer 3 alone and is realistically higher once layer 2 framing and encryption are counted. The third is headroom: the deliberate margin above modelled peak that absorbs burst, growth and the traffic that reroutes onto this link when another one fails. Multiply demand by the overhead factor and then by the headroom factor and you have a capacity figure you can put on a purchase order. Comparing that figure to the circuit you already have gives utilisation, spare capacity and a hard ceiling on concurrent sessions.

How to use this calculator.

1. 01Enter concurrent users — sessions live at the same instant, not total headcount or total subscribers. A 500-person office rarely has 500 simultaneous video streams; peak concurrency is what sizes the link.
2. 02Enter the bit rate one session sustains and pick its unit. Take the figure from the application vendor's own documentation where you can. Everything here is bits per second with decimal prefixes: Kbps is 10³ bit/s, Mbps is 10⁶, Gbps is 10⁹.
3. 03Set protocol overhead. 0% shows raw payload demand. 2.74% is the derivable layer-3 floor for TCP over IPv4 at a full 1,500-octet Ethernet MTU. 10%, the default, is a realistic allowance for encrypted traffic with acknowledgements and some retransmission.
4. 04Set engineering headroom. This is your margin above peak, and it is a policy decision rather than a physical constant. 20% is a common starting point on access links; raise it if this circuit carries failover traffic for another.
5. 05Enter the capacity of the link you already have, in Mbps, to get utilisation, spare capacity and the maximum number of concurrent users that circuit supports.
6. 06Read the verdict line last. If it says the design is short, either buy the required capacity, cut the per-user bitrate, or accept that concurrency above the stated ceiling will queue and degrade.

The formula.

Step one is unit normalisation. The per-user rate is converted to Mbit/s using decimal factors only: Kbps is divided by 1,000, Gbps is multiplied by 1,000, Mbps passes through. There is no factor of 1,024 anywhere in this calculator, and there is no division by eight — nothing on this page is expressed in bytes per second.

Step two is raw aggregate demand: concurrent users multiplied by the normalised per-user rate. This is the payload floor. A link sized to exactly this figure would run at 100% utilisation with no margin for anything, and in practice would drop traffic the first time two users happened to burst together.

Step three grosses that figure up twice, and the order does not matter because multiplication commutes. The overhead factor is 1 + overhead/100 and accounts for bits on the wire that are not payload. The headroom factor is 1 + headroom/100 and accounts for the margin you have decided to design in. At the defaults, 1.10 × 1.20 = 1.32, so required capacity is 32% above raw demand.

Step four compares that requirement to the circuit you have. Utilisation is required divided by available, times one hundred, and is deliberately allowed to exceed 100% — an over-capacity design should show you 264%, not silently clamp to 100%. Spare capacity is available minus required and is deliberately allowed to go negative for the same reason.

Step five computes the concurrent-user ceiling. Divide the available capacity by the grossed-up per-user rate — per-user bit rate times the same 1.32 factor — and take the floor. Flooring is not cosmetic: a link that arithmetically supports 75.76 users supports 75 users, and rounding up here is exactly how capacity plans come to promise more than the circuit delivers.

Step six converts the required rate into an hourly volume, which is what shows up on a metered bill or a transit invoice. One megabit per second sustained for one hour is 3,600 megabits, which is 450 megabytes, which is 0.45 decimal gigabytes. So the coefficient is exactly 0.45 GB per Mbps-hour, and 100 Mbps sustained for an hour is exactly 45 GB. If your provider bills in binary gibibytes instead, divide by 1.073741824 — that is the whole difference, and it is 7.4%.

One modelling caveat that no amount of arithmetic fixes. This is a peak-concurrency model with a fixed per-user rate. It assumes every session sustains its stated rate simultaneously, which is conservative for bursty traffic such as web browsing and roughly accurate for constant-bit-rate traffic such as video conferencing or IP telephony. For heavily bursty populations, statistical multiplexing means the real peak is lower than N × R, and the correct tool is a concurrency-and-blocking model rather than a straight sum. Sizing to the straight sum simply costs money; sizing below it costs incidents.

A worked example.

Frequently asked questions.

References& sources.

1. [1]RFC 5136, 'Defining Network Capacity' (IETF, 2008). Source of the capacity definition used throughout this page: 'the maximum number of IP-layer bits that can be transmitted from the source S and correctly received by the destination D over the link L during the interval [T, T+I], divided by I', and of the statement that 'literature often overloads the term bandwidth to refer to what we have described as capacity in this document' — with the 802.11b example that gives 11 Mbit/s, 25 MHz and 8 Mbit/s as three different answers to the same question.
2. [2]NIST, 'Prefixes for binary multiples' (Reference on Constants, Units and Uncertainty). Source of the decimal-versus-binary convention stated on this page: for megabit per second, 'all telecommunications engineers use it to mean 10⁶ bit/s', while memory manufacturers use 2²⁰ for the megabyte; also the IEC 1998 binary prefix table (kibi 2¹⁰, mebi 2²⁰, gibi 2³⁰, tebi 2⁴⁰).
3. [3]RFC 791, 'Internet Protocol' (IETF, 1981). Source of the minimum IPv4 header used in the 2.74% overhead floor: of the Internet Header Length field, 'note that the minimum value for a correct header is 5' 32-bit words, i.e. 20 octets. Also the Total Length field, which 'allows the length of a datagram to be up to 65,535 octets'.
4. [4]RFC 9293, 'Transmission Control Protocol (TCP)' (IETF, 2022). Source of the minimum TCP header in the overhead floor: the Data Offset field is 'the number of 32-bit words in the TCP header', which without options is five words — 20 octets. This document obsoletes RFC 793 and six others and is the current TCP specification.
5. [5]RFC 894, 'A Standard for the Transmission of IP Datagrams over Ethernet Networks' (IETF, 1984). Source of the 1,500-octet MTU in the overhead floor: 'The maximum length of an IP datagram sent over an Ethernet is 1500 octets.'
6. [6]RFC 6349, 'Framework for TCP Throughput Testing' (IETF, 2011). Context for why a capacity figure alone does not determine achievable throughput: it defines the bandwidth-delay product as 'the product of a data link's capacity (in bits per second) and its end-to-end delay (in seconds)' and works through a 44.21 Mbps T3 at 25 ms round-trip time, giving roughly 1,105,000 bits in flight and a minimum TCP receive window near 138 KB.