File Download Time Calculator

Enter a file size and a line speed, get a realistic download time. Bits and bytes converted properly, decimal multipliers (so they match how ISPs and storage vendors advertise), and a 5% protocol overhead added to reflect what TCP/IP actually delivers on a real connection. The full working is shown so you can audit the result.

Explain like I'm 5 (what even is this calculator?)

Broadband speeds are sold in megabits per second. File sizes are sold in megabytes. There are eight bits in a byte, so the headline speed is one eighth of what you might expect if you assumed both numbers were the same kind of thing. This page does the conversion for you, adds the small overhead the network actually consumes, and tells you how long the download will take in days, hours, minutes and seconds.

Work out a download time

Decimal units. 1 GB = 1,000 MB, the way every download page advertises it.

The number ISPs put on the ad, in megabits per second.

Prove it (show the working)

Enter a file size and a line speed to see the workings.

The 5% overhead figure is a single sensible number for an estimate. Real-world TCP/IP, TLS handshake and retransmits sit in the 3 to 8 percent range. On a perfectly clean line at full speed the overhead is closer to 3 percent. On a flaky mobile connection it can be more than 10 percent. If you want a no-overhead figure, multiply the answer by 1 / 1.05.

Useful? Save this calculator: press Ctrl + D to bookmark it.

Why the headline speed never feels right

The single most common surprise with broadband is the gap between the speed on the ad and the speed on the file you are actually downloading. A 100 Mbps line is advertised as a hundred-something, the file is fifty-something MB, the download takes longer than fifty seconds, and it feels like the ISP is lying. The ISP is not lying, but they are also not making it easy. 100 Mbps is 100 million bits per second. A 50 MB file is 50 million bytes, which is 400 million bits. Divide one by the other and the answer is four seconds, plus the small overhead the protocol consumes. Once you have the conversion clear in your head, the numbers stop being mysterious.

What actually slows real downloads down

The calculator assumes the line is the bottleneck. Often it is not. On a busy Wi-Fi network the link to the router is the constraint, especially on older 2.4 GHz radios in a flat with a dozen neighbours on the same channel. On a long download from a small server, the server's upload pipe or its disk is the limit. On peak-time downloads through a congested ISP route, packet loss creeps up and TCP backs off. On mobile, the radio link varies second to second. If a download is consistently a long way below what the calculator predicts, the line speed is probably not the bottleneck. A speed test directly to a nearby server (Ookla, Fast.com) tells you whether you are getting what you pay for. If that test is fine but real downloads are slow, the issue is somewhere else in the path.

Bits, bytes, decimal and binary

The calculator uses decimal multipliers, where 1 GB is 1,000,000,000 bytes. ISPs use decimal. Storage vendors use decimal. macOS and most Linux file managers report decimal. Windows is the awkward one: it shows binary numbers (1 GB = 1,073,741,824 bytes) but labels them MB and GB anyway, which is where most of the confusion comes from. The strict labels for the binary versions are MiB, GiB and TiB (mebibyte, gibibyte, tebibyte). For a download-time estimate the decimal numbers line up cleanly with both the line speed and the published file size, so that is what this page uses. If you are working with a Windows file size and you want to be exact, multiply the displayed number by 1.0737 to get the decimal-equivalent in GB.

When the calculator is honest, and when it is not

The result is honest as a back-of-the-envelope estimate for a single download on a connection that is otherwise idle, where you are getting close to the advertised speed. It is not honest for: shared Wi-Fi during a family film night, downloads from a slow source, peak-time torrents that vary minute by minute, or any scenario where the line speed is not the binding constraint. Use it to set expectations before you queue up a 90 GB game install, not as a benchmark to argue with your ISP about. For that you need a sustained speed test on a wired connection at the same time of day.

Related calculators

Download time is one outcome. These cover the line behind it.

Frequently asked questions

Why doesn't a 100 Mbps line download a 100 MB file in one second?

Because Mbps is megabits per second and MB is megabytes, and there are eight bits in a byte. 100 Mbps is 100,000,000 bits per second, which is 12.5 megabytes per second of raw throughput. So a 100 MB file takes about 8 seconds at the wire, before you add the protocol overhead. The mismatch between bits-for-speed and bytes-for-storage is the single biggest reason real-world downloads feel slower than the headline number suggests.

Where does the 5% overhead come from?

TCP/IP wraps every packet in headers, TLS adds a handshake and per-record overhead, and the connection ramps up slowly under TCP slow-start. Add retransmits on any packet loss and the typical real-world overhead sits between three and eight percent. Five percent is a sensible single number for an estimate. On a clean fibre line at full speed it can be lower, on a flaky mobile connection it is higher.

Why decimal megabytes (1,000,000 bytes) and not binary (1,048,576)?

Because that is what every party in the transaction advertises in. ISPs sell speed in decimal Mbps. Storage vendors sell drives in decimal GB. Operating systems are split: macOS and most Linux file managers use decimal, Windows uses binary and labels it MB anyway, which is where confusion creeps in. For a download-time estimate the decimal numbers line up with the labels on both ends, so that is what we use.

Why does the result still feel optimistic on my actual connection?

The calculator assumes you are getting the full advertised speed end to end. In practice the bottleneck is often somewhere else: a busy Wi-Fi network, an old router, a slow server at the other end, peak-time congestion in the ISP's network, or a CDN node a long way away. If a download is consistently much slower than the calculator predicts, the line speed is probably not the limiting factor, the route is.

Does the calculator work for uploads as well?

Yes. The maths is the same in either direction, so put your upload speed in instead of your download speed and the result is your upload time. Just remember that on standard fibre-to-the-cabinet lines, upload is usually capped much lower than download, often around 20 Mbps even on a 200 Mbps download package. Full fibre lines are typically symmetric or close to it.