Why 300 Mbps downloads at 37.5 MB/s
Networks are measured in bits, storage in bytes, and there are eight bits in a byte. That single fact accounts for the entire gap between the number on your broadband bill and the number in your download manager. Divide megabits per second by eight and you have megabytes per second: 300 Mbps ÷ 8 = 37.5 MB/s.
The convention is not arbitrary. A serial link genuinely transmits one bit at a time, so its natural rate is bits per second, and every physical-layer standard from RS-232 to 400 Gigabit Ethernet is specified that way. Storage, by contrast, is addressed in bytes, because a byte is the smallest independently addressable unit in almost every architecture. Both units are correct for their own domain; the confusion only arises where the two meet, which is exactly where you are standing when you download a file.
Watch the capitalisation, because it is the only thing distinguishing the two in writing. A lowercase b is a bit and an uppercase B is a byte, so Mb/s and MB/s differ by a factor of eight. Marketing material and even some equipment vendors get this wrong; when a specification sheet is ambiguous, the giveaway is the magnitude. A consumer internet plan quoted at 500 is almost certainly 500 Mbps, because 500 MB/s would be a 4 Gbps line.
A second, smaller factor lurks behind the first. A decimal megabyte is 1,000,000 bytes; a mebibyte is 220 = 1,048,576 bytes. Windows Explorer, most Linux tools by default, and RAM specifications use the binary quantity but label it “MB”. Storage vendors and network standards use the decimal one. The ratio is 1.048576 at the mega scale, 1.073741824 at the giga scale, and 1.0995 at the tera scale — which is why a 1 TB drive shows up as 931 GB.
The three conversions, and the one that people get wrong
Bit rate to byte rate is a division by 8. This is exact and there is nothing to argue about: 1 Gbps = 125 MB/s, 100 Mbps = 12.5 MB/s, 25 Mbps = 3.125 MB/s.
Decimal to binary bytes multiplies by 106 and divides by 220. Starting from a bit rate, MiB/s = Mbps × 1,000,000 ÷ (8 × 1,048,576). For 100 Mbps that is 100,000,000 ÷ 8,388,608 = 11.9209 MiB/s. The 4.86% shortfall against 12.5 MB/s is not overhead and not a loss — it is the same quantity of data counted with a different-sized unit.
Rate to volume multiplies by time. Megabytes per second × 3,600 gives megabytes per hour; divide by 1,000 for gigabytes per hour. A 300 Mbps line running flat out moves 135 GB in an hour and 3.24 TB in a day, which is worth knowing before you assume an unmetered plan.
Rate to transfer time is where the mistake happens. The correct form is time = size in bytes × 8 ÷ bit rate in bits per second. Dividing a size in gigabytes by a rate in megabits gives a number with no meaning, and dividing a size in gibibytes by a rate in decimal megabytes silently overstates the time by 7.4%. Keep the base units consistent — convert everything to bits, or everything to decimal bytes — and the arithmetic behaves.
Real transfers run slower than any of this, for reasons that are not unit conversion. TCP/IPv4 headers over Ethernet consume roughly 4–8% of the wire rate for large packets, more for small ones. Wi-Fi, VPN encapsulation and mobile links cost more again. The overhead field on this page applies a flat reduction before every conversion so you can quote realistic throughput; leave it at zero when you want the pure unit conversion.
Worked example: a 25 GB file over a 500 Mbps link with 6% overhead
You need to move a 25 GB virtual-machine image across a 500 Mbps link, and you want a realistic estimate rather than the wire-rate fantasy.
- Apply the overhead. 500 × (1 − 0.06) = 470 Mbps of usable throughput.
- Convert to bytes. 470 ÷ 8 = 58.75 MB/s.
- Convert to binary units, for comparison with what your file manager will show. 470,000,000 ÷ 8,388,608 = 56.03 MiB/s.
- Convert the file size to bits. 25 GB × 109 = 2.5 × 1010 bytes, × 8 = 2.0 × 1011 bits.
- Divide by the rate. 2.0 × 1011 ÷ (470 × 106) = 425.5 seconds, or about 7 minutes 6 seconds.
- Sanity-check with the shortcut. 25 × 8,000 ÷ 470 = 425.5 s. Same answer — the shortcut is just steps 4 and 5 collapsed.
- Volume per hour. 58.75 MB/s × 3,600 ÷ 1,000 = 211.5 GB per hour. Sustained for a day that is 5.08 TB, which would breach most business plans with a fair-use clause.
Compare the 425.5 s answer with the naive one. Ignoring overhead gives 25 × 8,000 ÷ 500 = 400 s, so the overhead costs 25.5 seconds — 6% of the time, exactly as expected, because a 6% reduction in rate produces a 1/(1−0.06) = 6.4% increase in duration.
How to read the result
Compare like with like before you call your ISP. A speed test that reports 280 Mbps on a 300 Mbps plan is delivering 93% of the wire rate, which is normal once framing and TCP overhead are counted. A file download that reports 28 MB/s on the same line is delivering 224 Mbps — also fine, because a single TCP stream to a distant server is limited by round-trip time and window size, not by your access line.
The per-hour and per-month figures are ceilings, not forecasts. They assume the link runs at full rate continuously, which no real user does. Use them to check whether a data cap is even reachable, or to size an offsite backup window.
If a transfer time comes out longer than a day, reconsider the transport. Moving 100 TB over a 1 Gbps link takes about nine and a half days of continuous transfer. Physically shipping disks — which every major cloud provider offers as a service — is routinely faster for datasets at that scale, and the calculator flags any transfer beyond 24 hours for that reason.
Do not confuse the binary and decimal figures with a performance problem. If your download manager shows 11.9 and your calculation said 12.5, the difference is the unit, not the network.
Common connection speeds converted
| Link speed | MB/s | MiB/s | GB per hour | Time for 5 GB |
|---|---|---|---|---|
| 10 Mbps | 1.25 | 1.19 | 4.5 | 66 min 40 s |
| 25 Mbps | 3.13 | 2.98 | 11.25 | 26 min 40 s |
| 50 Mbps | 6.25 | 5.96 | 22.5 | 13 min 20 s |
| 100 Mbps | 12.5 | 11.92 | 45 | 6 min 40 s |
| 300 Mbps | 37.5 | 35.76 | 135 | 2 min 13 s |
| 500 Mbps | 62.5 | 59.60 | 225 | 1 min 20 s |
| 1 Gbps | 125 | 119.21 | 450 | 40 s |
| 2.5 Gbps | 312.5 | 298.02 | 1,125 | 16 s |
| 10 Gbps | 1,250 | 1,192.09 | 4,500 | 4 s |
MB/s = Mbps ÷ 8. MiB/s = MB/s ÷ 1.048576. GB per hour = MB/s × 3.6. Time for 5 GB = 40,000 ÷ Mbps seconds.
MB or MiB: what the standard actually says
IEC 80000-13 defines the binary prefixes kibi, mebi, gibi and tebi (KiB, MiB, GiB, TiB) precisely so that the SI prefixes can keep their decimal meanings. Under that standard, 1 MB is 106 bytes and 1 MiB is 220 bytes, full stop. Adoption is uneven: macOS and most storage vendors follow it, Windows and much older software still label 220 bytes as “MB”, and RAM is always quoted in binary units regardless of the label. Network rates are unambiguously decimal — a 1 Gbps interface is 1,000,000,000 bits per second, not 230.
Mistakes that produce a wrong answer
- Dividing by 10 instead of 8. A popular shortcut that is 20% wrong. There are eight bits in a byte; the extra loss people are half-remembering is protocol overhead, which is nearer 5%.
- Mixing binary file sizes with decimal rates. A file your OS calls 5 GB may be 5 GiB, which is 5.37 decimal GB. Use the GiB unit option rather than typing 5 GB.
- Assuming a single download saturates the link. One TCP stream over a long path is limited by window size divided by round-trip time. Parallel streams, not a faster line, are usually what fixes a slow single transfer.
- Quoting upload speed from a download figure. Most consumer connections are asymmetric; a 300/30 plan uploads at a tenth of the rate it downloads, and backups care about the second number.
- Ignoring the slowest hop. End-to-end throughput is set by the narrowest link and by the far end's own connection, not by your access speed alone.
- Reading storage-array throughput as network throughput. A disk subsystem quoted in MB/s must be multiplied by 8 before you compare it with an interface quoted in Gbps.
When unit conversion is not the question you have
This converter answers a units question. Two neighbouring questions need different tools. If you are trying to work out how fast a circuit needs to be for a given number of users and applications, that is a sizing problem — use the network bandwidth requirement calculator, which aggregates per-application bitrates with concurrency and peak factors. If you are trying to work out why a storage system cannot keep up with the network, the constraint is usually operations per second rather than raw throughput, and the RAID IOPS and write penalty calculator is the right model.
Latency deserves a mention because it is what people usually mean when they say a fast connection feels slow. Throughput and latency are independent: a satellite link can deliver 100 Mbps with 600 ms of round-trip delay, which is excellent for downloading a film and unusable for a video call. The relationship that ties them together is the bandwidth-delay product — bit rate multiplied by round-trip time gives the number of bits in flight, and a TCP window smaller than that product caps a single stream well below the link rate. That is the mechanism behind almost every “my gigabit line only downloads at 200 Mbps from that server” complaint.
Finally, capacity planning at the storage end uses the same decimal-versus-binary distinction as the rate conversion here. A drive sold as 8 TB presents 7.28 TiB to the filesystem, and array-level overheads come off that again — the RAID capacity calculator works through both steps. If you are moving that data to or from a cloud provider, egress is usually billed per gigabyte of decimal transfer, so the GB-per-hour figure on this page is the one that maps onto the invoice; the cloud VM monthly cost calculator covers the compute side of the same bill.