How to fix corrupted MP4 files with free tools

Option 1: VLC (easiest, works sometimes)

VLC has a setting for broken AVI files, and people often recommend it for MP4 too. It only really helps with AVI. For MP4, VLC’s real value is as a test: if VLC plays your file, the data is fine and you just need a clean rewrap.

To save a copy from VLC, use Media → Convert/Save, add your file, choose a profile, and save. Be aware this re-encodes the video, so quality drops a bit and it takes a while. FFmpeg (below) is better for this.

Option 2: FFmpeg remux

Install FFmpeg (on Mac, brew install ffmpeg; on Windows, download a build from ffmpeg.org and add it to PATH). Then, in the folder with your file, run: ffmpeg -err_detect ignore_err -i broken.mp4 -c copy fixed.mp4.

If you see a lot of “non-monotonous DTS” warnings or the result stutters, regenerate the timestamps: ffmpeg -fflags +genpts -i broken.mp4 -c copy fixed.mp4.

For files that play but won’t seek or won’t stream online, add -movflags +faststart to put the index at the front.

Option 3: untrunc for “moov atom not found”

If FFmpeg says “moov atom not found,” the file’s index was never written. FFmpeg can’t fix this on its own. untrunc can, if you give it a working clip from the same camera: untrunc good.mp4 broken.mp4. It reads how the good file is laid out and uses that to rebuild an index for the broken one.

This works well for phones, GoPros, DJI drones, and most dashcams. Our untrunc reference file guide goes deeper, and the moov atom explained covers why it happens.

Option 4: re-encode as a last resort

If parts of the video are physically damaged, a re-encode can paper over it: ffmpeg -err_detect ignore_err -i broken.mp4 -c:v libx264 -crf 18 -c:a aac fixed.mp4. You’ll get a file that plays, with smeared or frozen frames where the damage was. It’s worth doing only after the lossless options fail.

When to stop and use a tool

If you’ve tried all of this and still have nothing, or you just don’t want to install anything, open it in FixCorruptVideo. It runs these steps in order with checks between each, and gives you a free 15-second preview so you can see the result before paying.

Setting up the tools properly

Most of the methods on this page rely on two free tools: VLC and FFmpeg. VLC is a normal installer on Windows and macOS. FFmpeg is a command-line program, and installing it is where most people get stuck, so here is the short version.

On Windows, download a release build from gyan.dev or the BtbN GitHub builds, unzip it somewhere permanent like C:\ffmpeg, and add the bin folder to your PATH through System Properties, Environment Variables. Open a new Command Prompt and type ffmpeg -version. If it prints a version, you’re ready. Alternatively, winget install ffmpeg does all of this in one step on Windows 10 and 11.

On macOS, the easiest route is Homebrew: brew install ffmpeg. On Linux, your package manager’s version (sudo apt install ffmpeg on Ubuntu or Debian) is fine for repair work, even if it is a release or two behind.

Work in a folder that contains a copy of the broken file and nothing else important. Open the terminal in that folder (on Windows, type cmd in the File Explorer address bar; on macOS, right-click the folder with Option held and choose to open a terminal there). That way every command can use short filenames.

Reading what FFmpeg tells you

Before running any fix, ask FFmpeg what it sees: ffprobe -hide_banner broken.mp4. The output is short, and a few lines matter.

moov atom not found means the index is missing. Skip straight to the rebuild methods; remuxing and VLC’s repair won’t help.

Invalid data found when processing input usually means the start of the file is damaged, or the file isn’t really an MP4. Check the first bytes with a hex viewer: a real MP4 has the letters ftyp at byte 4. If you see RIFF it’s actually an AVI, and if you see mostly zeros the start of the file was wiped.

A stream listing with a sensible duration but errors during playback means the index is present and the damage is in the frames or the index is partly wrong. A remux often cleans this up.

A duration far shorter than the recording, for example two seconds for a ten-minute clip, means the index only covers part of the data. Rebuilding the index from the raw data recovers the rest.

Remux options that solve specific problems

The basic remux is ffmpeg -i broken.mp4 -c copy fixed.mp4. It copies every frame without re-encoding and writes a fresh container. Add flags to target particular symptoms.

-movflags +faststart puts the index at the front, which fixes files that stall in browsers and some TVs.

-fflags +genpts regenerates timestamps, useful when FFmpeg complains about non-monotonic DTS or the file plays at the wrong speed.

-err_detect ignore_err tells FFmpeg to keep going past damaged packets rather than stopping. Pair it with -c copy to salvage everything readable.

-map 0:v -map 0:a keeps only video and audio, dropping data tracks (telemetry, timecode, subtitles) that sometimes confuse players after damage.

-avoid_negative_ts make_zero shifts timestamps to start at zero, which fixes audio that starts before video or a black first second in some editors.

Combine them as needed: ffmpeg -err_detect ignore_err -fflags +genpts -i broken.mp4 -map 0:v -map 0:a -c copy -movflags +faststart fixed.mp4.

Rebuilding with untrunc, step by step

untrunc is the best-known free tool for rebuilding a missing moov atom. It needs a healthy reference file recorded on the same device with the same settings. The maintained fork by anthwlock has prebuilt Windows binaries and a simple GUI; on macOS and Linux you build it from source or run it through Docker.

The command is untrunc reference.mp4 broken.mp4. It analyses the reference to learn the codec settings and track layout, then scans the broken file and writes broken.mp4_fixed.mp4 next to it. Progress is printed as it goes.

If the output plays but the audio is garbled, try -s to step through the data more carefully, or test a different reference clip. If untrunc stops early with an error about an unknown atom, the broken file may contain a codec or track type the tool doesn’t understand, such as GoPro telemetry or a DJI subtitle track.

untrunc works well on mainstream phone and camera footage. It struggles with variable frame rate recordings, PCM audio, and unusual containers. When it fails, it fails visibly, which is useful: you know to try something else rather than shipping a subtly broken file.

Fixing playback that looks wrong rather than fails

Some MP4s open and play but look broken. The fix depends on the symptom.

Video plays sideways or upside down: the rotation flag is missing or wrong. Set it without re-encoding using ffmpeg -display_rotation 90 -i in.mp4 -c copy out.mp4 on recent FFmpeg versions, or rotate in any editor.

Colours look washed out or too dark: usually an HDR (HLG or PQ) clip shown on a player that doesn’t handle HDR. It isn’t corruption. Play it in a player with HDR support or tone-map it with a re-encode.

Audio is out of sync by a fixed amount: shift it with -itsoffset. For example, ffmpeg -i in.mp4 -itsoffset 0.3 -i in.mp4 -map 0:v -map 1:a -c copy out.mp4 delays audio by 0.3 seconds.

Audio drifts further out of sync as the clip plays: the timing table is wrong or the video is variable frame rate being treated as constant. A remux with -fflags +genpts sometimes helps; otherwise re-encoding the audio to the video’s length is the reliable fix.

Fixing many files at once

If a card full of clips was damaged, you don’t want to fix them one by one. On Windows, a one-line batch loop handles a folder: for %f in (*.mp4) do ffmpeg -i "%f" -c copy -movflags +faststart "fixed_%f". On macOS or Linux: for f in *.mp4; do ffmpeg -i "$f" -c copy -movflags +faststart "fixed_$f"; done.

Run ffprobe over the folder first to separate files with a missing index (which need rebuilding) from those that only need a remux. Sorting them saves a lot of time, because a remux loop will simply fail on the ones with no moov.

For rebuilds in bulk, untrunc can be scripted the same way with a single reference file, as long as every broken file came from the same camera with the same settings.

Which method to pick

If VLC plays it: remux. If ffprobe reports a missing moov: rebuild with a reference. If the file is mostly zeros or tiny: look for another copy, because there is nothing to rebuild. If a rebuild plays but shows heavy artefacts: the frames are damaged, and you can save the clean stretches by cutting around the damaged parts.

If none of the free tools give a clean result, or you’d rather not set them up, the repair page runs the same sequence of strategies automatically and shows a free 15-second preview of the result. Unlocking the full file costs $9/month or $29/year. For background on why the index matters so much, see what the moov atom is.

Fixing corrupted MP4 files on Windows without extra tools

Windows has no built-in MP4 repair, but it does have a few things worth trying before you install anything. First, right-click the file, choose Properties, and look at the size. A file of 0 KB has no data to repair; check whether the original is still on the camera or phone.

Second, open the file in the Photos app and in Media Player. If one plays it and the other doesn’t, the file is probably fine and the failing app lacks a codec. The HEVC Video Extensions from the Microsoft Store fix most iPhone and recent Android clips that refuse to open on Windows.

Third, if the file came from an SD card, run chkdsk X: /f on the card (replacing X with its drive letter) only after copying everything off it. Chkdsk can repair the file system’s view of a file whose size was recorded incorrectly, but it can also turn fragments into .chk files, so never run it on the only copy.

Fixing corrupted MP4 files on a Mac

On macOS, QuickTime is strict about MP4 structure, so many files that QuickTime refuses are only slightly damaged. Open the file in IINA or VLC first; if it plays there, a remux with FFmpeg will make it QuickTime-friendly.

If Finder shows the file but QuickTime says it can’t be opened and VLC shows nothing, the index is almost certainly missing. Install FFmpeg through Homebrew to confirm with ffprobe, then rebuild.

Photos library videos are stored inside the library package. If a clip in Photos won’t play, export the unmodified original (File, Export, Export Unmodified Original) to get the actual file to work on, rather than a re-encoded copy.

When the file is on a phone

Repairs are easier on a computer. On iPhone, AirDrop or a cable transfer to a Mac gives you the original file; on Android, connect via USB in file transfer mode and copy from DCIM. Avoid sharing through messaging apps, which re-compress and may refuse broken files entirely.

If the clip is too large to transfer comfortably, you can open the repair page in the phone’s browser; the repair runs on the phone and nothing is uploaded. The free 15-second preview shows whether the repair works before you spend anything, and unlocking costs $9/month or $29/year.

A worked example

A typical case: a 2.3 GB clip from an Android phone that shut down from the cold during a ski run. The gallery shows a thumbnail but playback fails. ffprobe reports moov atom not found. A remux fails for the same reason.

We record a 10-second clip on the same phone with the same camera settings, 4K at 30 fps, and use it as a reference. The rebuild scans the 2.3 GB of raw data, finds about 14 minutes of HEVC frames and matching AAC audio, and writes a new index. The repaired file plays in every player, with the final half-second missing, which was the part the phone never managed to write.

That is a normal outcome. The footage was always there; only the map was missing. See what the moov atom is for why this happens so often.

Keeping the fixed file

Once a method works, rename the output with a clear name and keep the original broken file and any reference clip alongside it. If you later find a better method, you can redo the repair from the same starting point. Back up the fixed file in at least two places before editing or sharing.

A quick decision checklist before you start

Before you pick a method, answer three questions. Does the file have a realistic size for its length? Did the recording stop abruptly, for example because a battery died or a card was pulled? Do you still have another clip recorded on the same device with the same settings? If the answers are yes, yes, and yes, an index rebuild using that healthy clip as a reference is almost always the fastest route to a fully playable MP4.

If the file is tiny, or shows as zero bytes, the problem is not the MP4 structure but missing data, and recovery from the original card or drive should come first. If the file plays but stutters or shows grey blocks, the index is fine and the damage is inside the frames, so the goal shifts to salvaging the clean parts rather than restoring every frame.