Why big uploads fail on phones — and how resume actually works

You start a 2 GB upload on your phone, switch to another app for thirty seconds, come back, and the progress bar is dead or back at zero. Nothing is broken. The operating system did exactly what it was designed to do.

What happens when you leave the tab

Mobile operating systems treat a backgrounded browser tab as a battery liability. As soon as your browser stops being the foreground app — you switch apps, you lock the screen, a call comes in — the system starts throttling it: timers are slowed to a fraction of their normal rate, and after a while the tab may be frozen outright or discarded to reclaim memory. When you come back, the page is often reloaded from scratch.

An in-progress upload does not survive that. The JavaScript driving it is not running, and any network request it owned goes with it. Locking the screen has the same effect as switching apps, and this is why "I started the upload and put the phone in my pocket" is the single most common way a mobile transfer fails.

Desktop browsers throttle background tabs too, but far less aggressively, and they do not get discarded under memory pressure the same way — which is why the same upload from a laptop usually just works.

Why some uploads can resume and others cannot

If a file is sent as one long request — the classic form POST — the connection is a single unit. Interrupt it at 90% and there is nothing to resume; the server has an incomplete body it must discard, and the next attempt starts from zero. This is why a two-hour upload that fails at the end is a total loss.

If a file is sent as a sequence of chunks, each chunk is its own request with its own index. The server records which indexes it has. On reconnection the client asks what is already stored and sends only the gaps. Interruptions become cheap: you lose at most the chunk that was in flight. This is the same idea behind resumable HTTP uploads generally, and it is why every service that handles multi-gigabyte files is chunked underneath.

Chunking also makes progress honest. A single-request upload reports how much data the browser has handed to the operating system, which can be far ahead of what the server has actually received — that is the progress bar that sits at 100% for a minute. Chunked progress counts acknowledged chunks, so it reflects real state.

Getting a large file up on the first attempt

1. Use a native app for anything large from a phone. This is the only structural fix. A native app can hold a foreground service or background task and keep running while you use the phone normally; a web page cannot, no matter how well written.
2. If you must use a mobile browser, do not leave the tab. Keep the browser in the foreground and the screen on for the whole upload. Some sites request a screen wake lock to help; the OS may still ignore it.
3. Prefer Wi-Fi, and stay in one place. Walking between access points forces a reconnection. On a chunked upload that is a hiccup; on a single-request upload it is a restart.
4. Shrink the file first if you can. Exporting a video at 1080p rather than 4K can cut it to a quarter, and the fastest upload is the one that has less to send.
5. Check the ceiling before you start, not at 95%. Free tiers usually have both a per-file size cap and a daily count, and hitting either after a long upload is the most annoying possible failure.

More guides