How it works
Download time = file size in bytes divided by (bits per second / 8). Every unit here is decimal SI rather than binary: 1 Mbps is 1,000,000 bits per second and 1 GB is 1,000,000,000 bytes, matching how ISPs advertise speed and how drives are labelled. Tick Apply ~10% real-world overhead and the time is multiplied by 1.111, the reciprocal of 90% goodput, covering TCP and IP headers, retransmits and bursty servers.
The speed Unit field is the one people get wrong. Kbps, Mbps and Gbps are bits; KB/s, MB/s and GB/s are bytes, and the eightfold gap between them is the whole reason this tool exists. Defaults are 100 Mbps against a 5 GB file, which comes out at 6m 40s. Six presets fill the file size in: MP3 song (5 MB), 1080p movie (5 GB), 4K movie (25 GB), OS install (5 GB), Game patch (50 GB) and AAA game (100 GB).
This is a straight division, so it assumes you hold your full advertised line rate for the entire transfer. It models nothing about the source server's own upload cap, Wi-Fi loss, evening congestion, disk write speed, or TCP slow start at the beginning of a connection. The overhead option is a single flat 10% allowance rather than a protocol simulation, and the conversion table always lists both the theoretical and the padded time regardless of the checkbox.
Frequently asked questions
How many MB/s is 100 Mbps? +
12.5 MB/s, because there are eight bits in a byte and the tool uses decimal megabits. The conversion table prints that directly, alongside the same speed expressed in Mbps and Gbps, whichever unit you originally typed in.
How long does a 100 GB game download take? +
At 100 Mbps, about 2h 13m theoretically, or roughly 2h 28m once the 10% overhead allowance is applied. The AAA game (100 GB) preset fills the file size in for you, so you only need to set your line speed.
Does the calculator use 1024 or 1000 for a gigabyte? +
1,000. Kilo, mega, giga and tera are all powers of ten here, for both speeds and file sizes, because ISPs and drive manufacturers use SI prefixes. Your operating system may report the very same file as a smaller number of gigabytes.
Why is my real download slower than the estimate? +
The maths assumes your full line rate end to end. In practice the source server may throttle you, Wi-Fi and peak-time congestion cut throughput, and connections need time to ramp up. The overhead checkbox only covers protocol overhead, around 10%.
What is the 1 GB at this speed row for? +
It is a fixed reference point: how long a single gigabyte takes at whatever speed you entered, independent of the file size field. Useful for mental arithmetic, since you can multiply it by however many gigabytes you actually need to move.
Bits, bytes and two kinds of prefix
Two conversions stack here and both catch people. Network speeds are quoted in bits per second and file sizes in bytes, a factor of eight — so a 100 Mb/s connection moves at best 12.5 MB/s. Then decimal and binary prefixes diverge: a decimal megabyte is 10⁶ bytes and a mebibyte 2²⁰, about 4.9% larger, and the gap widens with each prefix step to about 7.4% at giga and 10% at tera.
That second gap is why a 1 TB drive shows as roughly 931 GB — the manufacturer counted decimal terabytes and the operating system reported binary ones. Nothing is missing.
Why real transfers never hit the theoretical figure
Protocol overhead consumes part of every link: TCP/IP headers, acknowledgements and retransmissions typically cost several percent before anything else. Latency matters as much as bandwidth for many transfers, because a high-latency link with a small window size cannot keep enough data in flight to saturate its capacity regardless of how wide it is.
Storage on either end is frequently the real bottleneck, and on shared or asymmetric consumer connections the upload figure is often a small fraction of the download one. Plan transfers on measured throughput rather than on the line rate.