How Long Will That Download Take?

Time equals size divided by speed. If a file is 800 megabytes and your connection delivers 100 megabits per second, you cannot simply divide 800 by 100. Speeds quoted in Mbps are megabits per second, and there are 8 bits in a byte, so 100 Mbps is 12.5 megabytes per second (100 divided by 8). Now the division works: 800 MB divided by 12.5 MB/s is 64 seconds.

Forgetting that factor of 8 is the single most common mistake in download math, and it makes estimates come out eight times too optimistic. Whenever you mix a size (bytes) with a speed (bits), the ratio of 8 has to appear somewhere.

Just as with storage, there is a 1000-versus-1024 wrinkle. Network speeds are quoted in decimal, so a 'megabit' is exactly 1,000,000 bits, while a file's size in 'MB' might be counted in binary (1 MiB = 1,048,576 bytes) depending on the program. For a rough estimate the difference is small — a few percent — but for a precise figure you should convert everything to plain bits and bytes first, which is exactly what a good calculator does behind the scenes.

The formula gives a best-case number. In practice you rarely reach the full advertised speed. Protocol overhead — the extra data that carries addressing and error-checking — eats a few percent. Latency slows the start, the server may throttle you, Wi-Fi and mobile signals fluctuate, and a shared line is split between everyone using it at once.

A practical habit is to add 10 to 20 percent to any theoretical estimate. If a download is dramatically slower than predicted, the bottleneck is usually the server or the network in between rather than your own connection — which you can confirm by downloading something else at the same time.

Even a perfect link never delivers its headline number, because every byte of your file travels wrapped in headers. On a standard 1500-byte Ethernet frame, 20 bytes go to the IPv4 header and 20 to the TCP header, so roughly 2.7 per cent of the capacity is spent describing the payload rather than carrying it. IPv6 headers are larger, TLS adds record framing, and acknowledgements travel back up the link.

That puts a realistic ceiling on a 300 Mbps connection at around 36 MB/s rather than the arithmetic 37.5. Older serial links lost far more: Gigabit Ethernet over fibre and the first two generations of PCIe used 8b/10b line coding, spending ten symbols to send eight bits — a flat twenty-five per cent tax before anything else. Modern links use 128b/130b and give most of that back.

A single TCP stream is limited not by bandwidth alone but by how much data it may keep in flight before waiting for an acknowledgement. Divide the window by the round-trip time and you get the throughput: a classic 64 KiB window over a 150 ms intercontinental path tops out near 3.5 Mbps no matter how fat the link is. Window scaling lifts that ceiling enormously, but latency still sets the pace, which is why a nearby mirror beats a distant one on the same plan.

The bottleneck also moves around. Wi-Fi advertises a radio rate, not throughput; because the medium is half-duplex and shared, real-world results land near half the headline figure. A mechanical hard drive may not write faster than 120 MB/s; an encrypted transfer can be limited by a single CPU core; and the server at the other end has an upload budget shared among everyone downloading from it. The slowest link in that chain is your actual speed.