English ▾
Free, Fast & Secure Online Tools
A failed video upload is unusually frustrating because the error message almost never names the real problem. “Upload failed” covers six quite different situations, and the useful first step is not retrying — it is working out which one you have. The symptom tells you.
That list resolves most cases in ten seconds. The rest of this explains each one.
Every platform has a ceiling, and they vary enormously — a few megabytes for a messaging app, several gigabytes for a video host. Phone video is the usual culprit: a few minutes at 4K produces a file far bigger than people expect.
Compressing the video is the direct fix, and for phone footage the saving is usually large because the original is encoded for recording speed rather than for size. Reducing 4K to 1080p alone cuts the data rate to roughly a quarter.
This is the cause people miss, because the file extension looks fine. .mp4 is a container — a box. What matters is the codec inside it, and an MP4 can contain H.264, H.265/HEVC, AV1 or others.
H.264 is accepted essentially everywhere. H.265/HEVC is where uploads break, and it is what recent iPhones and many cameras record by default to save space. The file plays perfectly on the device that made it and is rejected by the service.
The fix is converting to MP4 with H.264 video and AAC audio. That combination is the lowest common denominator and is accepted by every platform worth uploading to.
Services impose limits in both directions. Too high — 8K, or 120 fps — and the platform may refuse it. Too low, or an unusual aspect ratio, and a service expecting vertical video may reject a square one.
Variable frame rate causes its own trouble. Screen recorders and some phone apps produce VFR footage, where the frame rate changes moment to moment. Many upload pipelines expect constant frame rate and either fail or produce audio that drifts out of sync. Re-encoding at a constant 30 or 60 fps resolves it.
A transfer that stops at a different percentage each attempt is a connection problem, not a file problem. Large uploads are vulnerable because they hold a connection open for a long time, and a brief drop is enough.
Wired beats wireless. A smaller file beats a patient one — compressing first often succeeds where retrying does not, simply because there is less time in which something can go wrong.
Stopping at the same point every time points at the file. This commonly happens when a recording was interrupted — the battery died, the app was force-closed — leaving a video whose index was never written. It often still plays, because players tolerate what upload validators do not.
The usual sign is a file that plays but cannot be seeked, or whose duration shows as zero. Re-encoding it rebuilds the structure and is usually enough.
No sound. The audio codec was not supported, so the video was processed without it. AC-3 and DTS — common in files pulled from discs or TV recordings — are the usual offenders. Re-encode the audio to AAC.
Sideways video. Phones record in one orientation and store a rotation flag telling the player to turn the picture. Some upload pipelines ignore the flag. The fix is to rotate the video so the pixels themselves are the right way up, rather than relying on metadata.
When you do not know what the platform wants, this is the safe target:
Before converting, it is worth inspecting the file to see what codecs it actually contains. Two minutes of looking saves re-encoding something that was fine and leaving the real cause untouched.
Do not re-encode repeatedly. Every pass is lossy, so converting a video four times while guessing at the problem leaves you with a file that uploads and looks noticeably worse than the original. Identify the cause, convert once, from the original.