<-Back to all News

Why Your Large File Upload Is Slow — and What Actually Fixes It

2026 අගෝස්තු 16
3 min read
Upload speed, chunk size, parallelism, and per-file overhead. The four things that actually determine how long a multi-gigabyte transfer takes, and which ones you can control.

A large upload is almost always limited by one of four things: your connection's upstream bandwidth, the number of chunks sent in parallel, per-request overhead, and what the server does after the last byte arrives. Only the first is genuinely outside a transfer service's control.

1. Your upload speed is the hard ceiling

This is the one people miss, because broadband is marketed on download speed. Asymmetric connections are the norm: 100 Mbps down and 10 Mbps up is a common shape. At 10 Mbps, 3 GB takes roughly 40 minutes no matter what software you use. Run a speed test and read the upload figure before assuming something is broken.

2. Parallelism hides latency

A single upload stream on a long-distance link spends much of its time waiting for acknowledgements rather than sending data. Uploading several chunks concurrently fills that dead time. There is a limit — browsers cap concurrent connections per origin at around six, and each in-flight chunk occupies a server worker — so more is not automatically better, but one at a time is definitely worse.

3. Chunk size trades overhead against retry cost

Every chunk is a separate HTTP request that has to be authenticated and routed before a single byte is stored. Split a 3 GB file into 1.5 MB chunks and that is 2,000 round trips of fixed cost. Split it into 64 MB chunks and it is 48.

Bigger is not unconditionally better: a chunk that fails at 99% has to be re-sent in full, and the chunk can never exceed what the server accepts in one request. Somewhere in the tens of megabytes is usually the sweet spot for multi-gigabyte files.

4. What happens after the last chunk

This is the invisible one. The server has to reassemble the chunks into the final file, and if it does that inefficiently — or does it inside the last chunk's request while the browser waits — you get a progress bar that sits at 100% for minutes. Worse, if that reassembly exceeds a request timeout, the uploader may conclude the chunk failed and send it again, triggering the whole reassembly a second time.

If your transfers routinely stall right at the end, this is the first place to look.

What you can do

  • Use a wired connection. Wi-Fi adds packet loss, and loss hurts sustained uploads disproportionately.
  • Archive many small files into one. Per-file overhead is real and it compounds.
  • Do not compress already-compressed data. Zipping video or a .gz archive costs CPU time and saves almost nothing.
  • Keep the tab open. Browsers throttle background tabs.
  • Upload when the network is quiet if you share a link with an office or a campus.

Related: sending big data and how to send large files.

<-Back to all News