Work out how long a file takes to download or upload from its size, link speed, latency, MTU and packet loss, and see what limits your speed.
This free file transfer time calculator estimates how long a download or upload will take from the file size and link speed. Unlike a simple size-divided-by-speed sum, it includes IP and TCP header overhead, TLS, connection setup, round-trip time, the TCP window and packet loss. The result tells you whether the link, the TCP window or packet loss is the bottleneck, and shows the same file at other connection speeds. Use it to plan backups, cloud migrations, large uploads and remote site synchronisation, or to find out why a fast connection feels slow.
Enter a file size and a link speed and this calculator tells you how long the transfer takes. It also shows what is holding the transfer back, because the answer is often not the link. A 1 Gbps connection can crawl along at 5 Mbps if the round-trip time is long and the TCP window is small, and a little packet loss can cut speeds by more than half.
Everything runs in your browser. Add the round-trip time from our network latency calculator or from a ping, and the numbers reflect your real path instead of a perfect one.
The calculator works in four steps.
Transfer time is the bits to send divided by the throughput, plus the setup time.
1 GB over a 100 Mbps link. The file is 8,000,000,000 bits. At MTU 1500 the headers add about 2.7%, so 8.22 billion bits go on the wire. At 100 Mbps that takes about 82 seconds. The same file on a 1 Gbps link takes about 8 seconds.
Why a fast link can still be slow. Take a 1 Gbps link with a 100 ms round-trip time and a fixed 64 KB TCP window. The sender can have at most 65,535 bytes in flight, so throughput tops out at 65,535 × 8 ÷ 0.1 s, about 5.2 Mbps. A 1 GB file then takes roughly 25 minutes instead of 8 seconds. With window scaling turned on, the same transfer runs at line rate.
Packet loss. Take a 1 Gbps link, a 50 ms round trip, an MSS of 1460 bytes and 0.1% loss. The Mathis equation gives about 9 Mbps. The link is almost idle, and loss is the whole problem.
Raw link speed, no overhead:
These figures assume the full link speed is available and ignore headers, latency and loss. Real transfers are usually 3% to 10% slower on a clean link.
Convert the file size to bits (multiply bytes by 8), then divide by the link speed in bits per second. A 500 MB file is 4,000,000,000 bits, so on a 50 Mbps connection it takes about 80 seconds before overhead. This calculator also adds header overhead, connection setup and any limit from latency or packet loss.
The advertised speed is the best the link can do. Real downloads are also limited by the TCP window and round-trip time, packet loss, Wi-Fi quality, the speed of the server you are downloading from and your own disk. Run the calculator with your real round-trip time and loss to see which one applies.
Mbps is megabits per second and MB/s is megabytes per second. One byte is 8 bits, so divide Mbps by 8 to get MB/s. A 100 Mbps connection moves at most 12.5 MB/s.
Latency adds a fixed delay for the connection setup, and it caps throughput when the TCP window is small, because the sender has to wait a full round trip for acknowledgements. On a modern operating system with an auto-tuned window, latency mostly affects short transfers. On a fixed 64 KB window it limits every transfer.
The TCP window is how much data the sender may have in flight before it must wait for an acknowledgement. Maximum throughput is the window divided by the round-trip time. A 64 KB window on a 100 ms path caps out near 5 Mbps. Window scaling, on by default in current systems, raises the limit.
A lot more than most people expect. TCP treats loss as a sign of congestion and slows down. The Mathis equation estimates the loss-limited rate as (MSS ÷ RTT) × (1.22 ÷ √loss). At a 50 ms round trip, 0.1% loss caps a single connection near 9 Mbps, whatever the link speed.
Slightly. TLS record framing adds only a fraction of a percent more data, and TLS 1.3 adds one round trip to the handshake. For large files the difference is negligible. For many small requests the extra round trip adds up.
Network speeds use decimal units, and so does this calculator: 1 MB is 1,000,000 bytes. Operating systems sometimes show binary units (MiB, GiB), where 1 MiB is 1,048,576 bytes. For a 1 GB file the difference is about 7%.
Calculate network latency, ping distance, and data transfer times between geographic locations. Free tool for network engineers.
Calculate optimal TCP window sizes, bandwidth-delay product, and buffer settings. Generate OS-specific tuning commands to maximize throughput on high-latency links.
Find the fastest a single TCP connection can run on your link, given round-trip time, packet loss, MTU and an optional receive window.
Estimate the circuit size a site needs from user count, application mix, busy-hour concurrency and headroom.
Work out the effective MTU and the TCP MSS to set after VPN or tunnel overhead, and whether a packet will be fragmented.