Video Upload Stuck at 99%? Causes and Fixes
Why 99% Is the Cruelest Number in File Uploading
You've waited through the entire upload. It might have been 10, 20, or even 40 minutes for a large video file. And then, it just stops. Not at 50% or 80%, but right at the finish line: 99%. The progress indicator sits there, mocking you, while you debate whether to give it five more minutes or just kill the tab and start over. This isn't a random glitch. The 99% stall is a classic behavior in almost every browser-based upload system, including CocoConvert. That final 1% of the progress bar is a lie—it doesn't represent 1% of the data transfer. It's a catch-all for a series of server-side jobs that run *after* all the raw bytes have arrived: checksum verification, file integrity checks, format validation, and queue registration. Sometimes it even includes thumbnail generation or metadata extraction. All these complex steps get squashed into the bar's last tick. So, when your upload is stuck at 99%, your file has almost certainly reached the server. You're not watching data transfer anymore; you're watching the server think. Something in that post-receipt process has either stalled, timed out, or hit an error that hasn't been reported back to you yet. This distinction is critical. The fix for a network dropout at 80% is totally different from the fix for a server-side validation failure at 99%. This article lays out the most common causes, how to figure out which one is biting you, and the concrete steps to fix it. Some solutions take thirty seconds. Others require you to change how you prep your files before they ever touch the browser.
The Most Common Causes Behind the 99% Freeze
Before you start clicking buttons and hoping for the best, let's figure out what's actually going wrong. Five issues account for the vast majority of 99% stalls. **Browser connection timeout.** HTTP connections aren't meant to stay open forever. If the server's post-upload processing takes longer than your browser's keep-alive window (usually 60–120 seconds in Chrome, but configurable in Firefox via network.http.keep-alive.timeout), the browser gives up and silently drops the connection. The file is uploaded, but the final confirmation handshake from the server never arrives, leaving your progress bar in limbo. **Hitting a server-side file size limit.** CocoConvert has a 2 GB per-file limit on free accounts and 8 GB on Pro plans. If your file is 2.1 GB on a free plan, the server might accept the entire data stream before checking the size during the final validation step. This gives you the frustrating experience of a 99% freeze instead of a clear, immediate error message. **Corrupted or non-standard container.** Anyone who's fought with a finicky export knows this pain. An .mp4 file with a broken moov atom or an .mkv with a bad header might pass an initial file type check but will fail the deep inspection on the server. We see this a lot with files from older versions of DaVinci Resolve (before 17.4) and some GoPro firmware, which were known to create files with misaligned metadata. **ISP-level packet shaping.** Your Internet Service Provider might be interfering. Some providers, especially on residential plans, throttle or inspect large file transfers. This won't stop the upload, but it can delay or drop the final acknowledgment packets from the server. If your uploads consistently freeze at home but work fine on your phone's hotspot or a VPN, your ISP is the likely culprit. **The tab went idle.** Modern browsers are aggressive about saving resources. Chrome (since version 108) and Safari (since iOS 16) will ruthlessly throttle background tabs. If you clicked away from the CocoConvert tab during a long upload, your browser may have choked the JavaScript process managing the session, severing the connection right before the final handshake.
How to Diagnose Your Specific Situation in Under 3 Minutes
Don't just guess. You can narrow down the cause in three minutes with your browser's own tools. Before you try the upload again, open the developer tools (F12 in Chrome and Firefox, Option+Command+I on Mac) and click on the Network tab. Filter the requests by 'XHR' or 'Fetch'. Now, watch this tab as the upload stalls at 99%. Find the main upload request in the list. If its status stays 'pending' for more than 90 seconds, you're looking at a server processing delay or a connection timeout. The problem isn't your network. But if you see a 4xx or 5xx status code, the server actively rejected your file. The 'Response' tab for that request will usually contain a message explaining why. These error codes are your best clues. A `413` error means your file is over the size limit. A `415` means it's an unsupported format. A `504` signals that the server itself timed out during processing. Each code points to a different solution. Outside the browser, do the obvious check: is your file too big? In your CocoConvert account, go to Account → Plan Details to confirm your upload limit. Then, right-click your video file and check Properties (Windows) or Get Info (Mac) for its exact size. If the file is within 5% of your plan's limit, that's a huge red flag. Finally, run the definitive test. Try uploading a small, known-good file, like a 30-second, 720p MP4 exported from VLC or HandBrake. If that sails through, the problem lies with your original file. If the small file also stalls, the issue is environmental—your browser, network, or account configuration.
Fixes for Network and Browser-Related Stalls
If your diagnosis points to a connection timeout or browser throttling, these fixes should get you sorted out. **Keep the tab active.** I know it sounds trivial, but for uploads over 500 MB, this is the most common fix. Just keep the CocoConvert tab in the foreground for the entire upload. Don't minimize the window or switch to another tab. If you absolutely must multitask, Chrome's 'Tab Keep Alive' extension can help, but nothing is as reliable as simply staying on the page. **Switch browsers.** My blunt advice: if you're hitting 99% stalls on files over 1 GB in Chrome, just use Firefox. Firefox has a longer default connection keep-alive timeout and is generally more graceful with long-running server tasks. It's simply more patient. Don't bother switching to Edge; it's based on Chromium and behaves identically to Chrome in this regard. **Disable browser extensions temporarily.** Your ad blocker or privacy extension might be interfering with the final connection handshake. The easiest way to check is to open an Incognito/Private window (which usually disables extensions) and retry the upload. If it works, an extension is your culprit. Go back to a normal window and disable them one-by-one to find the offender. **Test your network path.** If you think your ISP is throttling you, try the upload using your phone's mobile hotspot. If it completes successfully, your home internet is the problem. A VPN like NordVPN or Mullvad can sometimes bypass this packet shaping, but it's not a guaranteed fix and the added latency can slow down the whole transfer. **Clear DNS cache and flush sockets.** If you're still stuck and using Chrome, it's time for a deep clean. Navigate to `chrome://net-internals/#sockets` and click 'Flush socket pools', then go to `chrome://net-internals/#dns` and click 'Clear host cache'. This forces the browser to resolve stale connection data that can cause uploads to hang.
Fixes for File-Specific Problems
Your small test file uploaded perfectly, but your main video keeps stalling. This means the file itself is the problem. Here’s how to fix it. **Re-mux without re-encoding.** This is the magic bullet. Many file issues—broken moov atoms, bad metadata, non-standard container structures—can be fixed by re-muxing. This process uses FFmpeg to rewrite the file's container without touching the video or audio streams, preserving 100% of the quality. It's as fast as copying the file. The command is simple: `ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4` The `-c copy` part tells FFmpeg to copy the streams directly, not re-encode them. The `-movflags +faststart` flag is extra credit; it moves key metadata to the start of the file for better streaming performance. For MKV files, the command is even simpler: `ffmpeg -i input.mkv -c copy output.mkv` If you don't have FFmpeg, the free GUI tool HandBrake can do the same thing. Just open your file, make sure the codec settings match the source, and export. The newly re-muxed file will almost always upload without a hitch. **Compress to reduce file size.** If your file is bumping up against your plan's size limit, the solution is to make it smaller. HandBrake's H.265 encoder at RF 28 is fantastic for this, often cutting file size by 40–60% compared to H.264 with very little visible quality loss. For a 1.9 GB file, this can easily get you under 1 GB. In HandBrake, go to Video → Video Codec → H.265 (x265), set Quality to RF 28, and let it run. **Check for file corruption.** As a final check, ask `ffprobe` (part of FFmpeg) to inspect your file: `ffprobe input.mp4`. If it spits out errors like 'moov atom not found' or 'Invalid data found when processing input', the file is genuinely damaged. No upload service can fix this. You'll need to go back to your original editing software and re-export it.
What CocoConvert Is Working On (and What It Can't Fix)
Let's be direct: some 99% stalls are genuinely on our side, caused by a limitation in CocoConvert's current architecture. Our system currently uses a single-request HTTP upload. A more robust method, used by services like Google Drive and Dropbox, is chunked multipart uploading. This approach splits a large file into small 5–10 MB pieces, uploading and confirming each one individually. It's far more resilient to connection drops and server timeouts, which is why you rarely see a 99% freeze on those platforms. Our engineering team is actively building a chunked upload system, and we're targeting a rollout in Q3 2026 for Pro accounts, with free accounts to follow. Until that new system ships, uploads over 1 GB on slow or unstable connections are more fragile on CocoConvert than on some other services. That's an honest limitation. If you regularly work with very large files (2 GB+) and hit these failures, the most reliable workaround is to compress the file with HandBrake before you upload. There are also problems no web service can fix. We can't repair issues with your ISP or local network. If you have high packet loss (check at fast.com or run a ping test to 8.8.8.8), big uploads will always be a gamble. And please, if you're uploading a file over 500 MB, use a wired Ethernet connection. Wi-Fi, especially the crowded 2.4 GHz band, is prone to interference that causes packet loss and makes large transfers fail. Finally, if a file is truly corrupted by the recording device or editing software, our servers can't magically repair it. You must perform the re-muxing step with FFmpeg on your own machine before you start the upload.
Quick Reference: 99% Stall Checklist
In a hurry? Here's the condensed checklist to solve your upload stall without re-reading the whole article. **First, check the basics:** - Confirm your file size is under your plan limit (Account → Plan Details on CocoConvert) - Keep the browser tab active and in the foreground during the entire upload - Try uploading in an Incognito window to rule out extension interference **If the problem persists:** - Open DevTools → Network tab and check the status code on the upload request - 413 = file too large; compress with HandBrake and retry - 415 = unsupported format; check CocoConvert's supported formats list - 504 = server timeout during processing; re-mux with FFmpeg and retry - Pending with no response = connection timeout; switch to Firefox or try mobile hotspot **For large files (over 1 GB):** - Re-mux with FFmpeg using `-c copy -movflags +faststart` before uploading - If still failing, compress to H.265 RF 28 in HandBrake to reduce file size - Use a wired Ethernet connection instead of Wi-Fi **If nothing works:** - Run `ffprobe` on your file to check for corruption - Contact CocoConvert support with the exact file size, format, and the error code from DevTools — that information cuts diagnostic time significantly - Consider whether the file needs to be re-exported from your editing software rather than fixed after the fact The good news is that the 99% stall is almost always fixable. That FFmpeg re-mux step alone resolves the problem for roughly 60% of users who report this issue to our support team. It works because it cleans up the file's internal structure, which is exactly what the server is checking—and rejecting—at the very end of the upload process.