How to fix a corrupted MP4 file

Before anything else: make a copy

Copy the broken file somewhere safe and work only on the copy. Some “repair” apps overwrite the original, and a few editors will happily re-save a half-read file, which throws away the parts they couldn’t understand. If the clip came off an SD card, copy it to your computer first and stop recording on that card until you’re done.

Write down what recorded it (phone model, GoPro, DJI, OBS, dashcam) and what happened: battery died, app crashed, card was pulled out, download stopped at 90%. That one sentence decides which fix will work.

Step 1: figure out what kind of broken it is

Look at the file size. A 10-minute 4K clip that’s 3 GB probably has its data and just lost its index. A clip that’s 200 KB when you expected 300 MB was truncated during a copy or download, and no tool can invent the missing part. Go back to the source if you can.

Next, try VLC. If VLC plays it but your phone, Windows player, or editor refuses, the file is mostly fine and only needs to be rewrapped. If VLC shows nothing or a frozen frame, the index is probably missing entirely, which is common after a crash mid-recording. Our page on what a corrupted MP4 actually is explains these cases in more detail.

Step 2: rewrap it without re-encoding

If the file plays in VLC, a remux usually fixes it. With FFmpeg installed, run ffmpeg -err_detect ignore_err -i broken.mp4 -c copy fixed.mp4. The -c copy part matters: it copies the video and audio as-is instead of compressing them again, so you lose no quality and it finishes in seconds.

If seeking is broken or the clip won’t stream, add -movflags +faststart. That moves the index to the front of the file, which is what web players and phones expect.

Step 3: the index is gone (crash, dead battery, pulled card)

When the camera never got to write its index, remuxing fails with “moov atom not found.” The fix here is to rebuild the index from a healthy clip shot on the same device with the same settings. The open-source tool untrunc does exactly this, and it’s the step most generic repair apps skip. We wrote a separate guide on using a reference file with untrunc.

Settings matter more than people expect. A reference clip shot at 4K30 won’t help rebuild a 1080p60 file. Record 10 seconds with the same resolution, frame rate, and stabilization setting, then use that.

Step 4: when nothing local works

If you don’t want to install command-line tools, our online repair runs these same steps automatically: it diagnoses the file, tries a lossless rewrap first, then index rebuilding, and only re-encodes as a last resort. You see a free 15-second preview before you pay anything, so you know whether the fix worked before spending money. MP4 and MOV files are repaired in your browser, so they’re never uploaded.

If the preview doesn’t play, don’t buy the repair. Some files really are beyond saving, usually ones where the actual video data was overwritten or never got written to the card.

How an MP4 is built, in plain terms

An MP4 is a container with boxes inside it. The big one, mdat, holds the raw compressed video and audio, often 99% of the file. A much smaller box, moov, holds the map: how many frames there are, how big each one is, where each sits in mdat, and when it should be shown. A third tiny box, ftyp, sits at the very start and says what kind of MP4 this is.

Players don’t read mdat front to back like a tape. They read the map first and then jump straight to the frames they need. That’s why a file can contain 3 GB of perfectly good footage and still refuse to open: without the map, the player has no idea where frame one starts. It’s also why the right repair is so often small and fast. You’re rebuilding a few megabytes of bookkeeping, not the video itself.

Cameras normally write mdat while recording and only write moov when you press stop. Anything that interrupts that last step, a dead battery, a pulled card, a crashed app, an overheating shutdown, leaves you with a full mdat and no moov. If you want the deeper version, read what the moov atom is.

Matching the symptom to the fix

“This file is not supported” or “moov atom not found”: the map is missing. Remuxing won’t help because there’s nothing to copy. You need an index rebuild, ideally with a reference clip from the same camera.

Plays in VLC, fails in QuickTime, Photos, Premiere, or on a TV: the map exists but has small errors, or it sits at the end of the file and the player wants it at the front. A lossless remux with -movflags +faststart fixes this in seconds.

Plays for a while, then freezes or jumps to the end: usually a truncated file whose map points past the real end of the data, or a copy that stopped partway. Check the file size against what you expect. If it’s short, look for the original before repairing anything.

Audio plays but the picture is black or green: the video track is either missing its codec setup data (the part that tells the decoder how the stream was encoded) or the frames are damaged. Rebuilding with a reference file restores the setup data. Green blocks that move around usually mean real data damage, and only part of the clip can be saved.

Picture plays but no sound, or the sound drifts out of sync: the audio track’s timing table is wrong. A remux sometimes fixes it; otherwise the audio has to be re-timed against the video, which our repair does automatically when it detects drift.

FFmpeg commands worth knowing

Check what FFmpeg sees before changing anything: ffprobe -v error -show_format -show_streams broken.mp4. If it lists a video stream with a resolution and a duration, the map is at least partly there. If it errors out immediately, the map is gone.

Lossless rewrap, the first thing to try: ffmpeg -err_detect ignore_err -i broken.mp4 -c copy -movflags +faststart fixed.mp4. Nothing is re-compressed, so quality is identical to the original.

Keep only the video if the audio track is what’s broken: ffmpeg -i broken.mp4 -map 0:v -c copy video-only.mp4. You can then try to rescue the audio separately and combine them later.

Re-encode as a last resort, when the stream itself has damaged frames: ffmpeg -i broken.mp4 -c:v libx264 -crf 18 -preset medium -c:a aac fixed.mp4. This smooths over broken frames but takes time and costs a little quality. A CRF of 18 is visually close to the original for most footage.

One honest warning: if FFmpeg prints thousands of “invalid NAL unit” or “error while decoding” lines, the problem isn’t the container. Rewrapping will produce a file that opens but still looks broken.

Device-specific notes

iPhone: clips cut off by a full storage warning or a crash in a third-party camera app are common. iPhones record HEVC by default, so your reference clip must also be HEVC (Settings → Camera → Formats → High Efficiency). Footage recovered from iCloud is rarely corrupted; if it is, it’s usually an incomplete sync, and re-downloading fixes it.

Android: Samsung, Pixel, and others vary a lot, but the same rule holds: record a short reference clip with the same lens, resolution, and frame rate. Slow-motion and HDR modes produce differently structured files, so match those too.

GoPro: GoPro splits long recordings into chapters (GX01…, GX02…). Usually only the last chapter breaks when the battery dies. GoPro files also carry an extra telemetry track; that’s normal, and a good repair keeps or drops it without hurting the video.

DJI drones: a crash or a battery swap mid-flight often leaves an unfinished MP4. DJI also writes a low-resolution proxy (LRF file) on some models; if the main file is lost, that proxy is worth keeping as a backup.

Dashcams and security cameras: many write in short loops and overwrite old files. Pull the card quickly after an incident. Cheap dashcams sometimes write non-standard MP4s that play only in their own app; a remux usually makes them normal.

OBS and screen recorders: if OBS crashes while recording to MP4, the file is lost without a rebuild. That’s why OBS suggests recording to MKV and remuxing later, and it’s good advice. See why OBS recordings break if that’s your case.

Mistakes that make repairs harder

Running five different repair apps on the original. Each one may write a “repaired” version over the source, and some truncate data they don’t understand. Always work on copies.

Formatting the card “to fix it”. If the camera says the card has errors, formatting wipes the file table you might need for recovery. Copy everything off first, including files that look broken.

Re-encoding first. Converting a broken MP4 in a free online converter often produces a smaller, blurrier file that hides the problem without solving it. Lossless options should always be tried first.

Renaming the extension. Changing .mp4 to .mov or .mkv doesn’t change what’s inside. It occasionally gets a different player to try harder, but it repairs nothing.

Paying before you’ve seen anything. Any repair service should show you a sample of your own fixed footage first. Ours shows a free 15-second preview, and you only pay ($9 a month or $29 a year) if you want to download the full file.

What a good result looks like

After a successful repair, the file should open in at least two different players (say, VLC and your system player), seek properly when you drag the timeline, and show the right duration. Watch the first few seconds, a section in the middle, and the last few seconds. The end is where interrupted recordings are most likely to be rough.

It’s normal to lose the final second or two of a recording that was cut off by a dead battery. The camera hadn’t finished writing that data to the card. It’s not normal to lose minutes; if that happens, the repair tool probably misread the frame structure, and trying again with a better reference clip usually helps.

If you edit the footage afterward, import the repaired file rather than the broken one, and let your editor build fresh previews. Editors cache data about the original file and can show old errors until that cache is cleared.

How to stop it happening again

Stop recordings properly, and wait a second before turning the camera off or pulling the card. Keep batteries above 15–20% for long takes. Use name-brand cards with the speed rating your camera asks for (V30 for most 4K, V60 or V90 for high-bitrate modes), and format them in the camera, not on a computer.

For long screen recordings or streams, record to a crash-tolerant format (MKV, fragmented MP4) and convert afterward. For anything you can’t reshoot, a wedding or a once-in-a-lifetime trip, run two cameras or record a backup to a second card if your camera supports it.

And keep a short healthy clip from each camera you own. If a file ever breaks, that clip is often what makes a full repair possible.

A short decision path you can follow today

Start with the cheapest test: copy the file somewhere safe and try opening the copy in VLC. If VLC plays it end to end, the footage is intact and you only need a remux to make other players happy. If VLC plays part of it, note the timestamp where it stops; that tells you roughly how much data is actually present.

If VLC refuses entirely, run ffprobe on the copy. An error that mentions the moov atom means you need an index rebuild. An error about invalid data at the very start often means the first few kilobytes were overwritten, which a rebuild with a reference clip can usually work around.

If the file size is zero or a round number like exactly 4.0 GB, stop and look for another copy. A zero-byte file has nothing to repair, and a file capped at exactly 4 GB was probably cut by a FAT32 card, which means the next chunk of the recording may exist as a separate file on the card.

Once you know which case you are in, the fix is usually quick. If you’d rather skip the command line, open the file on the repair page. You get a free 15-second preview of the repaired clip before paying anything, and if it looks right you can unlock the full file for $9/month or $29/year.