The calculation
Transfer time is size divided by speed, with a unit conversion in the middle:
seconds = (file size in bits) ÷ (speed in bits per second)
The conversion is where mistakes happen. File sizes are in bytes and connection speeds in bits, with 8 bits to a byte. A 5 GB file on a 100 Mbps connection takes 5 × 8,000 ÷ 100 = 400 seconds, or about 6 minutes 40 seconds at theoretical maximum.
Why you never reach the advertised speed
Real throughput typically runs 10–20% below the headline figure, and sometimes far below. The causes stack.
Protocol overhead is unavoidable: TCP and IP headers add roughly 40 bytes to every packet, and acknowledgements consume upstream capacity. That alone accounts for several percent.
The server's upload capacity caps everything. A gigabit connection downloading from a server limited to 10 Mbps per client gets 10 Mbps.
Wi-Fi is usually the bottleneck in home networks. Real Wi-Fi throughput is commonly half the negotiated link rate or less, and degrades with distance, walls, and competing devices.
Contention — shared capacity in your building or neighbourhood — is why evening speeds are often noticeably worse.
Disk write speed can limit very fast connections. A slow external drive cannot absorb a gigabit stream.
Latency and the bandwidth-delay product
For large single transfers over long distances, bandwidth is not the only limit — latency matters too, in a way that surprises people.
TCP sends a window of data and waits for acknowledgement. The maximum throughput of a single connection is bounded by:
throughput = window size ÷ round-trip time
With a 64 KB window and 200 ms latency, a single TCP connection tops out at about 2.6 Mbps — regardless of whether the link is 100 Mbps or 10 Gbps. This is why transatlantic single-stream transfers can feel slow on a fast connection.
Modern systems mitigate this with window scaling, and download managers use parallel connections for the same reason. It is also why CDNs exist: reducing distance reduces latency, which raises achievable throughput.
Download versus upload
Most consumer connections are asymmetric — far more download capacity than upload. Cable and DSL commonly offer 10–20 times more down than up.
This catches people out when backing up, video calling, or uploading large files. A 500/20 Mbps connection downloads a 5 GB file in about 80 seconds and uploads the same file in around 33 minutes.
Fibre connections are frequently symmetric, which is a substantial practical difference for anyone who uploads regularly.
Making transfers faster
Use a cable. Ethernet eliminates the most common bottleneck in home networks outright.
Compress first. Text, code, and documents often compress by 70–90%. Already-compressed formats — JPEG, MP4, ZIP — will not compress further.
Use a transfer tool that supports resume and parallel streams for large files. It also protects against having to restart after an interruption.
Check the source. If a download is slow from one mirror, another may be far faster — the bottleneck is frequently at the far end rather than yours.
Frequently asked questions
Why is my download slower than my connection speed?
Protocol overhead, the server's own capacity, Wi-Fi limitations, network contention, and disk write speed all reduce real throughput. Achieving 80-90% of the advertised rate is typical.
How do I convert Mbps to MB/s?
Divide by 8, since there are 8 bits to a byte. A 100 Mbps connection delivers a theoretical maximum of 12.5 MB/s.
Why are big transfers slow even on a fast connection?
Latency limits single TCP connections. Throughput is bounded by window size divided by round-trip time, so a long-distance transfer can be slow regardless of bandwidth. Parallel connections and CDNs both address this.
Why is uploading so much slower than downloading?
Most consumer connections are asymmetric, with 10 to 20 times more download than upload capacity. Fibre connections are often symmetric, which makes a large practical difference for uploads.