What we'll cover
A while back I was trying to send a 4GB project archive to a client. Decent laptop, decent wifi, nothing weird. The upload climbed to about 82%, paused, and then the browser threw up ERR_CONNECTION_RESET. I tried again. Same thing, except this time it died at 71%. Different number, same heartbreak.
If you've landed here, you've probably seen your own version of that: the bar that freezes at 99%, the "upload failed, please try again" that lies about why, the transfer that works fine for a 50MB file and falls apart the moment you go big. I ended up building file-transfer software partly because I got tired of this, so I've debugged most of these failures from the inside. Here's the honest breakdown.
First, what does "failed" actually look like?
"Failed" isn't one thing. The exact symptom is a clue to the cause, so pay attention to which one you're getting:
- Dies at a random percentage (60%, 80%, never the same) → usually a network drop or a proxy size limit.
- Freezes at 99% or 100% forever → the bytes finished uploading, but the server is still chewing on the file (or the response got lost). This one fools everyone.
- Instant rejection → a hard size limit kicked in before anything really uploaded.
- Crawls and then times out → your connection is too slow to finish before something gives up waiting.
Keep your symptom in mind. We'll match it to a cause as we go.
Reason 1: The invisible 100MB wall
This is the one almost nobody knows about, and it's the reason my 4GB upload kept resetting. Most websites today sit behind a CDN or proxy (Cloudflare being the big one). Those proxies often cap how big a single request body can be. On a lot of plans that cap is 100MB. Go over it and the proxy quietly kills the connection mid-stream.
Here's the cruel part: your browser keeps showing progress past the limit. It's counting the bytes it has handed to your network card, not the bytes the server actually accepted. So you'll watch it sail past 100MB to 300MB before the reset catches up. That's why the failure point looks random — you're seeing buffering lag, not the real cutoff.
💡 How to tell if this is your problem
If small files (under ~90MB) always work and large ones always die somewhere in the first few hundred MB with a "connection reset," it's almost certainly a proxy body limit, not your internet. No amount of retrying will help — the wall is fixed.
The fix on the receiving end is to either route uploads around the proxy or, better, split the file into chunks small enough to slide under the limit and reassemble them on the server. That's a job for whoever runs the site, but it's worth knowing so you stop blaming your wifi.
Reason 2: Timeouts you never see
There are at least three clocks running during an upload, and any one of them can end your transfer:
- The browser's patience — many uploaders abort if no progress happens for 30–60 seconds.
- The server's request timeout — if the whole upload takes longer than the server allows, it hangs up.
- The proxy's read timeout — same idea, one layer out.
The sneaky one is the 99% freeze. Once your last byte is sent, the server still has to write the file to disk and respond. On a big file that pause can be long — and if the uploader's "no progress" timer is still running, it gives up right at the finish line. I've shipped that exact bug myself and had to teach the uploader to stop the clock once the body was fully sent. If your transfers consistently die at the very end, this is usually why.
Reason 3: Your upload speed (the boring math)
Most home connections are wildly asymmetric. You might download at 200 Mbps and upload at 10. People forget that "upload" is the number that matters here, and it's almost always the smaller one. Quick reality check:
- At 10 Mbps up, a 5GB file takes roughly 70 minutes.
- At 20 Mbps up, that's about 35 minutes.
- At 50 Mbps up, you're looking at around 14 minutes.
Run a quick speed test and look only at the upload figure. If it's in single digits, a multi-gig transfer is going to take a while no matter what tool you use, and the longer it runs, the more chances it has to hit one of those timeouts above. Slow isn't the same as broken — but slow makes broken more likely.
Reason 4: One dropped packet kills the whole thing
A traditional single-shot upload is fragile by design: it's one long connection. If your wifi hiccups for two seconds at minute 18 of a 20-minute transfer, the whole thing can collapse and you start over from zero. Mobile data is the worst offender here because the connection shifts between towers as you move — if you're uploading from a phone, see sending files from your phone without an app for mobile-specific tips.
This is why chunked uploads matter so much. When a file is sent in 50MB pieces, a blip only costs you one piece, not the entire file. If a tool you're using restarts from 0% every time it stumbles, that's a sign it isn't chunking — and it's worth switching to one that does for anything large.
Reason 5: Your laptop went to sleep
Embarrassingly common, and I've done it too. You start a big upload, walk away to make coffee, and the screen locks. Many laptops throttle or suspend network activity when they sleep, and browsers can pause background tabs to save battery. You come back to a dead transfer and assume the service is broken. It wasn't — your machine clocked out.
How to actually fix it
Working roughly from easiest to most effective:
- Plug in. Both power (so the machine doesn't sleep) and, if you can, an ethernet cable. Wired connections don't drop the way wifi does, and they're usually faster up.
- Keep the tab awake. Don't minimize it, don't let the screen lock. For long uploads, nudge the mouse occasionally or change your sleep settings.
- Use a tool that chunks and resumes. This is the single biggest win for large files. Chunked uploads survive blips and don't restart from zero. This guide to sending large files compares the methods in detail.
- Don't fight a hard size limit. If a service caps uploads at 2GB, retrying a 4GB file forever won't help. Either compress it or use a service built for the size you actually have.
- Try a wired or different network before you blame the file. Coffee-shop wifi and crowded mobile data are common culprits.
💡 A note on the tool I build
I'll be upfront: I make Realtime Sender, so I'm biased. The reason it exists is everything above — uploads are sent in chunks so a dropped connection costs one piece instead of the whole file, large transfers aren't blocked by proxy limits, and the progress bar tells you the truth. You can send a file without an account to see if it holds up on your connection. If another tool already works for you, great — the fixes here apply everywhere.
The 60-second checklist
Before you rage-quit, run through this:
- Is the file bigger than the service's stated limit? (Check first — saves you 20 minutes.)
- Is your laptop plugged in and set not to sleep?
- Can you switch to ethernet, or a less crowded network?
- Does the tool resume on a stumble, or restart from 0%?
- Did it die at 99%? That's the server finishing up — give it a moment, and if it always fails there, it's a timeout bug on their end.
- Still stuck? Try a service built for big files. Not every tool is, and that's fine.
The short version
Large uploads fail for boring, fixable reasons: hidden proxy limits, impatient timeouts, slow upload speeds, fragile single-shot connections, and laptops that fall asleep. None of it is your fault, and almost none of it means your file is "too big" in any real sense. Match your symptom to the cause above, plug in, use something that chunks, and the 80%-and-dies cycle usually stops.
If email attachment limits are part of your problem, here are the better alternatives. And if you just want something that handles big files without the drama, that's exactly what we built Realtime Sender to do.