The conversion, in one line
File sizes are in megabytes, connection speeds in megabits. There are eight bits to a byte, and the two factors of eight cancel almost exactly:
seconds = size in MB ÷ speed in Mbps × 8
A 700 MB file on a 100 Mbps line: 700 ÷ 100 × 8 = 56 seconds. That is the theoretical figure, and it is the number most people will see quoted.
Why the real time is longer
Two things account for nearly all of the difference:
Protocol overhead. A transfer is not a continuous stream. TCP/IP headers, acknowledgements and the connection handshake consume 5–15% depending on the protocol, and web transfers over TLS add a further layer. The calculator's overhead field defaults to 8%, which is typical for HTTPS. On a slow connection, HTTP/2 or HTTP/3 multiplexing recovers part of that, which is why a modern connection often gets closer to the theoretical figure than an old one.
Contention. Your 100 Mbps is shared with everything else on the network, and the ISP's own routing adds delay for long-distance transfers. This is the usual reason a transfer that "should" take a minute takes three, and it cannot be predicted from the speed alone — which is why the calculator treats it as a percentage you set rather than pretending to know it.
Speed in different units, and why MB/s is friendlier
ISPs quote Mbps (megabits per second), downloads report MB/s. Divide by eight to convert:
100 Mbps → 12.5 MB/s · 1 Gbps → 125 MB/s · 10 Mbps → 1.25 MB/s
Every download manager shows MB/s, and the mismatch is a frequent source of confusion — 100 Mbps really is only 12.5 MB/s, so a "fast" 1 Gbps line moves a 700 GB disk image in about 90 minutes, not ten.
What actually limits a real download
Bandwidth is rarely the constraint. In order of how often they bite:
- Source-side limits. The far end may be throttling. A 1 Gbps line downloading from a server with a 50 Mbps cap is a 50 Mbps transfer.
- Contention. Other devices, video calls, cloud backups running concurrently.
- Packet loss and retransmission. On a poor Wi-Fi or congested link, lost packets are resent, and throughput falls non-linearly — this is why Wi-Fi downloads stall rather than degrade gracefully.
- Latency-bound transfer. Many small files (a package install, a folder of images) are latency-bound rather than bandwidth-bound, which is why parallel connections or multi-connection download tools help there and not for a single large file.
Upload and the asymmetry problem
Most connections advertise a much lower upload speed — commonly 10 or 20 times less than download. Sending a 2 GB video backup on a 100/10 Mbps line takes 2 ÷ 10 × 8 = 1,600 seconds, about 27 minutes, versus 2.7 minutes to download the same file. The calculator reports this explicitly, because "my upload is 100 Mbps" is a common misreading of a symmetric label.
Estimating a batch
For anything repeated — a season of video, a backup set, an OS image per machine — multiply once. Ten 700 MB files on that 100 Mbps line is about 10 minutes theoretically, closer to 13 with overhead. The data size converter handles the unit arithmetic when sizes are in different units, and the bandwidth calculator runs the transfer time in both directions at once.
Frequently asked questions
Why does my download take longer than the speed suggests?
Protocol overhead consumes 5–15% depending on the protocol and TLS, and the connection is shared with other traffic. The source server may also be the bottleneck — your line being fast does not help if the far end is slow.
How do I convert Mbps to MB/s?
Divide by 8, because there are 8 bits in a byte. 100 Mbps is 12.5 MB/s, and 1 Gbps is 125 MB/s. Download managers show MB/s, which is why the numbers seem to disagree with your plan.
Why is my upload much slower than my download?
Most connections are asymmetric — 100 Mbps down might be 10 Mbps up. So a 2 GB file uploads in about 27 minutes on that connection versus 2.7 minutes to download. The calculator flags this when you switch to upload mode.
What is the overhead percentage?
An estimate of what the protocol stack consumes. Around 8% is typical for HTTPS, 5% for plain HTTP, and it rises on a lossy connection because lost packets must be resent. The calculator lets you set it, since the real value depends on your connection.