How long will this upload take?

It is arithmetic, and the mistake almost everyone makes is mixing up megabits and megabytes. The formula, a table to skip it, and why the bar looks frozen when nothing is wrong.

3 min read

"How long will this take?" is the question everyone asks after starting a large upload and watching a progress bar that does not appear to move. The answer is arithmetic, and it is worth being able to do in your head before you commit an afternoon to it.

The number you need is your upload speed

Most connections are asymmetric: download is fast, upload is a fraction of it. The figure on your broadband bill is almost always the download one, and it is not the number that matters here.

Run a speed test and look at the upload figure. A "500 Mbps" home line might upload at 20. Business fibre is often symmetric; cable and DSL rarely are.

The formula

The two units differ by a factor of eight, which is where most bad estimates come from: files are measured in megabytes (MB), connections in megabits per second (Mbps).

minutes = (file size in MB x 8) / (upload Mbps x 60)

A rougher version you can do while talking: divide your Mbps by 8 to get MB per second. At 20 Mbps that is 2.5 MB/s, so a 1 GB file takes about 1000 / 2.5 = 400 seconds, near enough seven minutes.

A table to skip the maths

File 5 Mbps 20 Mbps 50 Mbps 200 Mbps
100 MB 3 min 40 sec 16 sec 4 sec
1 GB 27 min 7 min 3 min 40 sec
10 GB 4.5 hrs 70 min 27 min 7 min
50 GB 22 hrs 6 hrs 2.2 hrs 33 min

Add roughly 10-20% to whatever this says. Protocol overhead, encryption, and the fact that nobody sustains their theoretical maximum all take a cut.

Why it is slower than the table

  • You are sharing. A household streaming video, or an office of forty people, is using the same upstream.
  • Wifi is not the connection. It is a shared radio between you and the router, and on a busy 2.4 GHz band it can be a fraction of your line speed. Ethernet removes this variable entirely.
  • Small files have overhead. Ten thousand small files take much longer than one file of the same total size, because each one costs a round trip.
  • Distance costs. Higher latency to a far-away server reduces throughput, particularly on a single connection.

Why the bar seems stuck

Two different things get read as "frozen".

Progress that only updates once per chunk. If a tool sends the file in 6 MB slices and only moves the bar when a slice completes, a slow connection means the number sits still for a minute at a time. Nothing is wrong; the reporting is just coarse. A bar that climbs continuously through each chunk is telling you the same truth in a more useful way, which is why it is worth having.

The stall at 99%. Usually the bytes have arrived and the server is reassembling and verifying them. For a large file this genuinely takes a moment. Closing the tab here is the one thing that can turn a finished upload into a failed one.

Making it faster

  • Plug in. Ethernet over wifi is the single biggest improvement available to most people.
  • Send less. A 1080p review export instead of the master turns hours into minutes, and is usually what the recipient wanted. See sending large video files.
  • Upload once, share many times. A link sent to eight people is one upload, not eight.
  • Start it and walk away — but only if the transfer resumes after an interruption. Chunked uploads with automatic retries make an overnight upload a reasonable plan; a single-stream upload does not.
  • Stop your own machine sleeping. Plug the laptop in and check the sleep settings.

When the answer is "too long"

If the honest estimate is over a day, reconsider the shape of the job: send selects now and the full set overnight, or put a disk in a courier bag. There is no shame in the physical option — for a few terabytes it is still the fastest thing available.

Related: why large uploads fail for when it is not just slow, and how to send large files for the methods.