Video Upload Stuck at 99%? Causes and Fixes
Why 99% Is the Cruelest Number in File Uploading
You've waited through the entire upload bar — sometimes for 10, 20, even 40 minutes on a large video file — and then it stops. Not at 50%, not at 80%, but at 99%. The progress indicator just sits there, spinning or frozen, while you stare at it wondering whether to wait another five minutes or kill the tab and start over. This specific failure point is not random. The 99% stall is a well-documented behavior across virtually every browser-based upload system, including CocoConvert. It happens because the final 1% of an upload doesn't actually represent 1% of the data transfer. Instead, it covers a cluster of server-side tasks that happen after the raw bytes arrive: checksum verification, file integrity checks, format validation, queue registration, and sometimes thumbnail generation or metadata extraction. All of that gets rolled into the visual progress bar's last tick. So when your upload appears stuck at 99%, the file data itself has almost certainly already reached the server. What you're watching is the server doing its post-receipt work — and something in that process has either stalled, timed out, or hit an error it hasn't surfaced to you yet. Understanding that distinction matters, because the fix for a network dropout at 80% is completely different from the fix for a server-side validation failure at 99%. This article covers the most common causes, how to diagnose which one you're dealing with, and concrete steps to resolve each. Some fixes take 30 seconds. Others require changing how you prepare your file before uploading.
The Most Common Causes Behind the 99% Freeze
Before trying random fixes, it helps to know what's actually going wrong. There are five causes that account for the vast majority of 99% stalls. **1. Browser connection timeout.** HTTP connections have idle timeouts. If the server's post-upload processing takes longer than the browser's keep-alive window (typically 60–120 seconds in Chrome, configurable in Firefox via network.http.keep-alive.timeout), the browser silently drops the connection. The upload is done, but the confirmation handshake never arrives, so the progress bar never moves. **2. File size hitting a server-side limit.** CocoConvert enforces a 2 GB per-file limit on free accounts and 8 GB on Pro accounts. If your file is 2.1 GB and you're on a free plan, the server may accept the incoming data stream and then reject the file during validation — which happens at the very end of the process. The result looks like a 99% freeze rather than an upfront error. **3. Corrupted or non-standard container.** A .mp4 file with a broken moov atom, or an .mkv with a malformed header, will pass the initial MIME-type check but fail during server-side inspection. Files exported from certain older versions of DaVinci Resolve (specifically versions before 17.4) and some GoPro firmware are known to produce files with misaligned metadata that triggers this. **4. ISP-level packet shaping.** Some internet service providers throttle or inspect large file transfers, particularly on residential connections. This doesn't stop the upload but can cause the final acknowledgment packets to be delayed or dropped. You'll see this pattern if uploads consistently freeze at 99% on your home network but complete normally on mobile data or a VPN. **5. Tab going idle.** Browsers — especially Chrome since version 108 and Safari since iOS 16 — aggressively throttle background tabs. If you switched away from the CocoConvert tab during a long upload, the browser may have deprioritized the JavaScript process managing the upload session, breaking the final handshake.
How to Diagnose Your Specific Situation in Under 3 Minutes
Rather than trying every fix at once, spend three minutes narrowing down the cause. Open your browser's developer tools (F12 in Chrome and Firefox, Option+Command+I on Mac) and click the Network tab before you attempt the upload again. Filter by 'XHR' or 'Fetch' requests. When the upload stalls at 99%, look for the upload request in the list. If it shows a status of 'pending' for more than 90 seconds, you're likely dealing with a server processing delay or a connection timeout — not a network problem on your end. If it shows a 4xx or 5xx status code, that's a server rejection, and the response body will usually tell you why (look in the Response tab). If you see a 413 error, your file is over the size limit. A 415 means unsupported format. A 504 means the server timed out during processing. These are distinct problems with distinct solutions. Outside the browser, check your file size against your account tier. On CocoConvert, go to Account → Plan Details to confirm your current upload limit. Then right-click your video file and check Properties (Windows) or Get Info (Mac) to see the exact file size. If it's within 5% of your plan limit, that's a red flag. Finally, run a quick test: try uploading a small, simple file — a 30-second, 720p MP4 exported from VLC or HandBrake. If that completes without issue, the problem is specific to your original file, not your connection or account. If the small file also stalls, the issue is environmental (browser, network, or account configuration).
Fixes for Network and Browser-Related Stalls
If your diagnosis points to a connection timeout or browser throttling issue, these steps resolve the problem in most cases. **Keep the tab active.** This sounds trivial but it's the fix that works most often for uploads over 500 MB. Keep the CocoConvert tab in the foreground for the entire upload. Don't minimize the window. On Chrome, you can install the 'Tab Keep Alive' extension to prevent background throttling if you need to multitask, though staying on the tab is more reliable. **Switch browsers.** Firefox handles long-running XHR uploads more gracefully than Chrome in most configurations because it has a longer default connection keep-alive timeout. If you're on Chrome and consistently hitting 99% stalls on files over 1 GB, try Firefox as a direct comparison. Edge (Chromium-based) behaves identically to Chrome for this purpose, so switching to Edge won't help. **Disable browser extensions temporarily.** Ad blockers, privacy badgers, and VPN extensions can interfere with upload completion handshakes. Open an Incognito/Private window (which disables most extensions by default) and retry the upload. If it succeeds in Incognito, the culprit is one of your extensions — disable them one at a time in a normal window to identify which one. **Test your network path.** If you suspect ISP throttling, try the upload over your phone's mobile hotspot. If it completes without issue, your home ISP is likely the problem. A VPN can sometimes bypass packet shaping — NordVPN and Mullvad are commonly used for this — but this isn't a guaranteed fix and adds latency that can slow the transfer overall. **Clear DNS cache and flush sockets.** In Chrome, navigate to chrome://net-internals/#sockets and click 'Flush socket pools', then go to chrome://net-internals/#dns and click 'Clear host cache'. This resolves stale connection state that can cause uploads to hang near completion.
Fixes for File-Specific Problems
If your small test file uploaded fine but your actual video keeps stalling, the file itself is the issue. Here's how to address it. **Re-mux without re-encoding.** Many file-level problems — broken moov atoms, misaligned metadata, non-standard container structures — can be fixed by re-muxing the video through FFmpeg without touching the actual video or audio streams. This preserves full quality and takes roughly the same time as copying the file. The command is: `ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4` The `-movflags +faststart` flag moves the moov atom to the beginning of the file, which also improves streaming performance. For MKV files with header issues, use: `ffmpeg -i input.mkv -c copy output.mkv` If you don't have FFmpeg installed, HandBrake (free, GUI-based) can do the same thing: open your file, select the same codec settings as the source, and export. The re-muxed file will almost always upload cleanly. **Compress to reduce file size.** If you're near your plan's size limit, compress the file before uploading. HandBrake's H.265 encoder at RF 28 typically reduces file size by 40–60% compared to H.264 at similar quality. For a 1.9 GB file, that often brings it under 1 GB. Go to HandBrake → Video → Video Codec → H.265 (x265), set Quality to RF 28, and export. **Check for file corruption.** Run `ffprobe input.mp4` (part of the FFmpeg package) to check for errors. If you see messages like 'moov atom not found' or 'Invalid data found when processing input', the file is damaged and needs to be recovered or re-exported from source before any upload will succeed — on CocoConvert or anywhere else.
What CocoConvert Is Working On (and What It Can't Fix)
It's worth being direct about the platform's current limitations, because some 99% stalls are genuinely on CocoConvert's side. The current upload system uses a single-request HTTP upload rather than chunked multipart uploads. Chunked uploading — where the file is split into 5–10 MB pieces and each piece is confirmed individually — is far more resilient to connection drops and server timeouts. It's the approach used by services like Google Drive and Dropbox, and it's the reason those services almost never show a 99% freeze. CocoConvert's engineering team is actively developing a chunked upload system, with a target rollout in Q3 2026 for Pro accounts. Free accounts will follow. Until that ships, uploads over 1 GB on slow or unstable connections are genuinely more fragile on CocoConvert than on some alternatives. That's an honest limitation. If you're regularly converting very large files (2 GB+) and experiencing consistent failures, the most reliable current workaround is to compress the file first using HandBrake, as described in the previous section, and then upload. CocoConvert also can't fix problems that originate with your ISP or your local network hardware. If you're on a connection with high packet loss (check at fast.com or using a ping test to 8.8.8.8), large uploads will be unreliable regardless of which service you use. A wired Ethernet connection is significantly more stable than Wi-Fi for uploads over 500 MB — the 2.4 GHz Wi-Fi band in particular is susceptible to interference that causes sporadic packet loss without showing obvious speed degradation. For file corruption issues caused by the original recording device or editing software, CocoConvert's server-side processing can't repair the file. The re-muxing step with FFmpeg has to happen on your machine before the upload.
Quick Reference: 99% Stall Checklist
If you want a fast reference without re-reading the full article, here's the decision tree distilled into a checklist. **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 99% stall is fixable in the large majority of cases. The re-mux step alone resolves the problem for roughly 60% of users who report this issue to support, because it corrects container-level problems that the server's validator catches at the end of the upload process.