Bandwidth & Download Time Calculator

Compute any one of (transfer time, required throughput, transferable size) from the other two. Useful for sizing downloads on a slow connection, validating a backup window, estimating CDN cost, or sanity-checking a 'how long will this take' question. Bit-rate units (Mbps, Gbps) and byte-rate units (MB/s) are kept distinct — and decimal (KB = 1000) vs binary (KiB = 1024) prefixes are both supported. An overhead slider models the ~5–10 % loss from TCP/IP headers, ACKs, and framing.

Keeping bits and bytes apart is the whole point, because the factor of eight between them is the single most common error in this arithmetic. A connection sold as 100 Mbps delivers at best 12.5 MB/s, and the gap between the number on the bill and the number in a download manager is not the ISP shortchanging you; it is the unit. The decimal and binary prefixes add a second, smaller discrepancy: a drive labelled 1 TB holds 1000⁴ bytes, which an operating system reporting in TiB shows as 0.91.

The overhead slider accounts for what the protocol spends on itself, but it cannot model the reason most transfers fall short of their theoretical time. A single TCP connection on a long path is limited by the window size divided by the round-trip time regardless of how much bandwidth is free, which is why a transfer between continents can crawl on a fast link and why parallel streams fix it. Add to that a slow disk at either end, a shared uplink, per-connection throttling, and the fact that nobody's peak rate is their sustained rate.

The result is a floor rather than an estimate. Treat it as the best case the physics allows, and a real transfer that lands within a quarter of it is doing well.

For a backup window the number to plan against is the change rate rather than the total size, since an incremental run moves only what moved.