Download Time Calculator

Work out how long a transfer takes at a given line rate, with realistic protocol overhead applied instead of the marketing arithmetic.

Calculator Bandwidth & Data Runs in your browser
~6% for TCP/IPv4 over Ethernet with 1500-byte MTU.
Real transfers rarely reach 100% of line rate.
Try:

Result

Realistic transfer time
1h 14m 39s
Theoretical minimum
1h 6m 40s
at full line rate, zero overhead
Effective goodput
89.3 Mbit/s
Data volume
50.0 GB
46.6 GiB
Overhead cost
7m 59s
time lost to overhead and inefficiency

Same file at other line rates

Link speedRealistic timeGoodput
10 Mbit/s12h 26m 33s8.93 Mbit/s
100 Mbit/s1h 14m 39s89.3 Mbit/s
200 Mbit/s37m 20s178.6 Mbit/s
500 Mbit/s14m 56s446.5 Mbit/s
1000 Mbit/s7m 28s893.0 Mbit/s
2500 Mbit/s2m 59s2.23 Gbit/s
10000 Mbit/s45s8.93 Gbit/s
Bits versus bytes
Bytes and bits are the usual trap: a 100 Mbit/s link moves at most 12.5 MB/s before overhead, and around 11.8 MB/s after it. A "slow" 100 Mbit/s connection delivering 11 MB/s is performing correctly.

About Download Time Calculator

Transfer time is size divided by rate - but only after you account for the difference between line rate and goodput. Headers, acknowledgements, retransmissions and the fact that no real transfer sustains 100% of the wire all eat into the number a naive calculation produces.

When the network is not the bottleneck

Before buying more bandwidth, check what actually limits the transfer. A single TCP stream on a high-latency path is capped by the window and by loss, not by capacity. Many small files are dominated by per-file overhead and metadata operations rather than throughput. Encryption, compression and checksumming can saturate a CPU core well below line rate, and a spinning disk or a saturated storage array often tops out first. Measuring a single large file transfer and a many-small-files transfer separately tells you which problem you have.

Where the missing capacity goes

A 1500-byte Ethernet frame carries 1460 bytes of TCP payload over IPv4, plus 38 bytes of framing per packet including preamble and inter-frame gap. That is about 6% lost before anything goes wrong. Add IPv6 (20 more bytes of header), a VPN tunnel, or a 1492-byte PPPoE MTU and it grows. Single-stream TCP over a long path is limited further by the bandwidth-delay product, which is a separate calculation entirely.

Common use cases

  • Estimating a backup or migration window before committing to it.
  • Explaining to a customer why their 100 Mbit/s service downloads at 11 MB/s.
  • Comparing whether a link upgrade actually shortens a nightly job enough to matter.

Edge cases and gotchas

  • Storage vendors count 1 GB as 10^9 bytes; operating systems often show GiB (2^30). The 7% difference shows up in every capacity argument.
  • A single TCP stream on a high-latency path may not fill the link regardless of size - check the BDP calculator.

Frequently asked questions

Why do I only get 11 MB/s on a 100 Mbit/s link?
100 Mbit/s ÷ 8 = 12.5 MB/s of raw capacity, minus about 6% protocol overhead. Around 11.5-11.8 MB/s is the correct, healthy result.
Would a faster link halve my backup time?
Only if the network is the bottleneck. Disk throughput, encryption and per-file overhead frequently dominate on backup jobs with many small files.