Enter your file size and connection speed to find out how long a file transfer will take. Useful for planning backups, uploads, migrations and WAN transfers.
File Transfer Time Calculator
Enter a file size and a connection speed, get back how long the transfer will actually take. Useful for planning a backup window, sanity-checking a data migration timeline, or explaining to someone why "just copy it over the network overnight" isn't going to work for the amount of data they're talking about.
The formula, and the trap inside it
Transfer time = file size (bits) ÷ connection speed (bps). The part that catches people out is the same bits-vs-bytes confusion that shows up everywhere in networking: connection speed is quoted in megabits per second, file size is quoted in megabytes. A 100 Mbps connection moves data at 12.5 MB/s, not 100 MB/s — an 8x gap that matters a lot once you're estimating a multi-hour transfer window.
Some numbers to anchor expectations
- 1 GB over 100 Mbps — roughly 80 seconds
- 1 TB over 1 Gbps fibre — roughly 2.2 hours
- 10 GB VM image over a 50 Mbps WAN link — roughly 27 minutes
- 500 GB database backup over 10 Gbps LAN — roughly 7 minutes
Why real transfers run slower than the theoretical number
Actual throughput almost always lands under the connection's rated speed, and it's rarely just one cause: TCP/IP overhead eats a slice of the bandwidth, disk read/write speed can be the real bottleneck (a spinning HDD topping out around 150 MB/s doesn't care how fast the network is), congestion and firewall inspection both add delay, and encryption (SFTP, HTTPS) has its own overhead. On top of all that, WAN latency limits how large a TCP window can effectively be, which caps throughput independently of raw bandwidth. 60–80% of the theoretical maximum is a realistic expectation under good conditions — plan backup and migration windows around that number, not the number on the connection's spec sheet.