Bits sell connections, bytes measure files
Every confusion about internet speed starts with one convention: network rates are quoted in bits per second, and stored data is quoted in bytes. A byte is eight bits, so the number your provider advertises is eight times larger than the download-speed number your browser shows. A 100 Mbps line delivers at most 12.5 MB/s, and both figures describe exactly the same connection.
The notation is unforgiving: lower-case b means bits and upper-case B means bytes. Mbps and MB/s differ by a factor of eight even though they look almost identical in a sentence. IEEE 802.3, the Ethernet standard, defines its rates in decimal bits per second — a gigabit interface carries 10⁹ bits per second, not 2³⁰ — so no binary prefix enters on the rate side at all.
The reason for the split is historical and physical. A serial link transmits one symbol at a time and its rate is naturally expressed in bits; a byte boundary is a software convention layered on top. Storage, by contrast, is addressed in bytes, because that is the smallest independently addressable unit. Neither side is going to change, so converting between them is a permanent part of the work.
Beyond the factor of eight, two effects separate the advertised rate from the throughput you observe. Protocol overhead — Ethernet framing, IP and TCP headers, TLS records — consumes a share of every packet. And the end-to-end path may be limited by something other than your line: the server, an intermediate hop, or your own disk. The overhead field on this calculator handles the first; nothing handles the second except measurement.
Why overhead costs more time than its percentage suggests
The rate conversion is a single division: bits per second ÷ 8 gives bytes per second, and dividing again by 10⁶ gives MB/s. Going to binary units divides by 1,048,576 instead, which is why 12.5 MB/s is 11.921 MiB/s — the same rate, a different unit.
Transfer time is where care is needed, because time is inversely proportional to throughput. If overhead h removes a fraction of the line rate, the payload rate is R(1 − h) and the time becomes 8S ÷ [R(1 − h)]. The time therefore grows by a factor of 1 ÷ (1 − h), not by 1 + h.
Take a 6% overhead. The payload rate is 94% of nominal, and the transfer takes 1 ÷ 0.94 = 1.06383 times as long — an increase of 6.383%, not 6%. At 20% overhead the gap is much wider: 1 ÷ 0.80 = 1.25, a 25% increase in time from a 20% cut in throughput. The calculator states this figure explicitly whenever you enter a non-zero overhead, because reading the percentage straight across is the most common error in the whole calculation.
What value should you use? For a plain TCP/IPv4 transfer over Ethernet with standard 1,500-byte frames, headers and interframe gap account for a few per cent of the wire time. Encryption, small packets, tunnelling and wireless framing all push it higher, and a satellite or long-haul link may be limited by round-trip latency and window size rather than by header bytes at all. Treat the overhead field as a sensitivity control: set it to zero for the pure unit conversion, then try a few per cent to see how much the answer moves.
Worked example: 50 GB over a 300 Mbps line
You are pulling a 50 GB video archive over a connection sold as 300 Mbps, and you want to allow 6% for protocol overhead.
- Nominal rate in bits. 300 Mbps = 300 × 10⁶ = 300,000,000 bit/s.
- Payload rate after overhead. 300,000,000 × (1 − 0.06) = 282,000,000 bit/s, or 282 Mbps.
- Convert to bytes. 282,000,000 ÷ 8 = 35,250,000 B/s, which is 35.25 MB/s.
- In binary units. 35,250,000 ÷ 1,048,576 = 33.617 MiB/s.
- Gigabytes per hour. 35.25 × 3600 ÷ 1000 = 126.9 GB/h.
- The file in bytes. 50 GB = 50 × 10⁹ = 50,000,000,000 bytes.
- Transfer time. 50,000,000,000 ÷ 35,250,000 = 1,418.44 s, which is 23 min 38 s.
- Check the overhead effect. With no overhead the time is 50,000,000,000 ÷ 37,500,000 = 1,333.33 s, so overhead added 1,418.44 − 1,333.33 = 85.11 s. As a share, 85.11 ÷ 1,333.33 = 6.383%, which matches 1 ÷ 0.94 − 1 = 6.383% exactly. Six per cent of throughput cost more than six per cent of time.
One caveat on step 6: if the 50 GB figure came from Windows Explorer it is really 50 GiB = 53,687,091,200 bytes, and the transfer takes 53,687,091,200 ÷ 35,250,000 = 1,523.0 s, or 25 min 23 s. Switch the size unit to GiB in that case. The data storage unit converter shows the full byte counts for both readings.
Reading the result against what you actually see
The MB/s figure is a ceiling, not a forecast. It is the fastest the link alone can move payload bytes, and a real transfer meets it only when nothing else is the constraint.
If your measured speed is roughly one eighth of the advertised figure, nothing is wrong — you are comparing a byte rate to a bit rate. That is the single most common false alarm about internet speed. If your measured speed is a few per cent below the converted figure, that is overhead and it is expected. If it is half or less, look elsewhere: the source server's own upload capacity, a single-connection TCP window limited by latency, a Wi-Fi link slower than the wired line behind it, or a disk that cannot write as fast as the network delivers.
The GB-per-hour figure is the one to use for planning rather than curiosity. It answers questions like whether a nightly backup window is long enough, or how much of a monthly data allowance a continuous transfer consumes. At 100 Mbps you move 45 GB an hour, so a saturated line runs through a 1 TB monthly cap in about 22 hours of continuous use — 1,000 ÷ 45 = 22.2.
For sustained links rather than one-off files, the time side of capacity planning usually pairs with an availability target; the uptime SLA downtime calculator converts those percentages into hours. And if you want transfer time from a size and a speed you already have in matched units, the data transfer time calculator is the narrower tool.
Common connection speeds in byte terms
| Advertised speed | MB/s | MiB/s | GB per hour | Time for 50 GB |
|---|---|---|---|---|
| 25 Mbps | 3.125 | 2.980 | 11.25 | 4 h 26 min 40 s |
| 50 Mbps | 6.25 | 5.960 | 22.5 | 2 h 13 min 20 s |
| 100 Mbps | 12.5 | 11.921 | 45 | 1 h 6 min 40 s |
| 200 Mbps | 25 | 23.842 | 90 | 33 min 20 s |
| 300 Mbps | 37.5 | 35.763 | 135 | 22 min 13 s |
| 500 Mbps | 62.5 | 59.605 | 225 | 13 min 20 s |
| 940 Mbps | 117.5 | 112.057 | 423 | 7 min 6 s |
| 1 Gbps | 125 | 119.209 | 450 | 6 min 40 s |
| 2 Gbps | 250 | 238.419 | 900 | 3 min 20 s |
940 Mbps appears because that is a typical usable payload rate on a gigabit Ethernet handoff once framing is accounted for; the interface itself is rated 1,000 Mbps.
Rate prefixes are decimal; file-size prefixes often are not
A megabit is 10⁶ bits and a gigabit is 10⁹ bits, with no binary variant in use anywhere in networking. IEEE 802.3 rate names and SI prefixes agree completely on this point, which is why 1 Gbps ÷ 8 is exactly 125 MB/s with no awkward remainder.
File sizes are the messy side. Windows reports a 1 GB file by dividing bytes by 2³⁰, so its “1 GB” is 1,073,741,824 bytes — 7.374% more data than 10⁹ bytes, and 7.374% more transfer time. Whenever a size came from an operating system rather than from a specification, select the binary unit in this calculator.
Mistakes that make a transfer estimate wrong
- Treating Mbps and MB/s as the same unit. They differ by exactly eight. A speed test reporting 11.8 MB/s on a 100 Mbps line is showing you a healthy connection, not a broken one.
- Adding overhead to the time instead of subtracting it from the rate. A 20% overhead lengthens a transfer by 25%, because 1 ÷ 0.8 = 1.25. Apply the reduction to throughput and let the time follow.
- Using an operating-system file size with decimal math. A file Windows calls 4 GB is 4,294,967,296 bytes, so it takes 7.374% longer than a 4 × 10⁹ byte file.
- Assuming the link is the bottleneck. Source server capacity, TCP window size on a high-latency path, Wi-Fi, and disk write speed all cap real transfers below the line rate, and none of them appear in this calculation.
- Confusing download and upload rates. Most residential connections are asymmetric; sending a 50 GB archive can take many times longer than receiving it. Enter the direction you are actually using.
- Reading a burst rate as a sustained rate. Some plans allow a short burst above the committed rate. A short file finishes at the burst rate, a large one converges on the sustained rate.
Key terms
- Mbps
- Megabits per second: 10⁶ bits per second. The unit in which internet plans and Ethernet interfaces are rated.
- MB/s
- Megabytes per second: 10⁶ bytes per second, which is eight times as many bits. The unit browsers and file-copy dialogs display.
- MiB/s
- Mebibytes per second: 1,048,576 bytes per second. Reported by some transfer tools and by most Unix utilities in human-readable mode.
- Protocol overhead
- The share of the wire rate consumed by framing and headers rather than payload — Ethernet framing, IP, TCP and any encryption layer.
- Goodput
- The rate at which useful application data arrives, after overhead, retransmissions and protocol stalls. Always at or below throughput.
What this calculation cannot tell you
This is a bandwidth calculation, and bandwidth is only one of the two variables that govern a transfer. The other is latency, and it dominates in cases this formula handles badly.
A single TCP connection cannot exceed its window size divided by the round-trip time, regardless of how fast the link is. On a long-haul path with a 150 ms round trip, one connection with a 4 MB window tops out near 4,000,000 × 8 ÷ 0.15 = 213 Mbps no matter what you have bought. That is why bulk-transfer tools open many parallel connections, and why a 10 Gbps intercontinental link can feel slow to a single stream.
Small files behave differently again. Copying ten thousand 50 kB files takes far longer than one 500 MB file of the same total size, because each transfer pays connection setup, metadata and per-file latency that no rate conversion sees. Archive first, then transfer, when the file count is large.
Finally, this calculator assumes a constant rate for the whole transfer. Real throughput varies with congestion, with time of day, and with whatever else is sharing the link. Treat the answer as the best case for the link you described, and measure if the number matters. If you need the underlying size arithmetic in isolation, the Mbps to MB/s speed converter covers the rate conversion on its own.