Repair a Corrupted Video in Your Browser

What this page actually checks

Pick a video and this page walks the whole stream to find frames whose data is broken, then shows you where they are on a timeline. Repairing writes out a new file containing only the frames that decode, so the result plays without stalling. Everything runs on your device — nothing is uploaded.

Inside an MP4 or MOV, each H.264 or HEVC frame is stored as a chain: a length number, then that many bytes of picture data, then the next length, and so on until the frame's data runs out. The chain has to land exactly on the end. If a length is zero, or points past where the data stops, that frame's bytes are not what the file claims they are.

After checking packet lengths, the tool decodes each group of frames. If decoding fails, the group is excluded and checking resumes at the next keyframe; the timeline marks the affected group because the exact failing frame may be unknown.

If you have ever run a broken video through ffmpeg and seen `Invalid NAL unit size (0 > 1241)` scroll past, that is the same condition being reported. Players usually respond by stalling, skipping, or showing a smear of blocks — because that is all they can do with bytes that aren't there.

Verification requires a decoder for the video's codec. A browser that cannot decode the video cannot verify a repaired copy.

Two kinds of broken, and they look different

**Frames whose data is corrupted.** Something wrote the wrong bytes — an interrupted copy to a USB stick, a failing card, a sync that died halfway. The file's length and index are intact and the video opens normally, but individual frames inside are unusable. On the timeline these show up as marks scattered wherever the damage happened.

**Video that was cut short.** A download or transfer stopped early. The header still claims the original length, so players show a full-length scrubber, but the picture data simply ends partway through. This page detects it by comparing the length the file claims against the last frame it can actually reach — on the timeline it's one grey block at the end.

The two are worth separating because they call for different expectations. Scattered damage often costs you a second here and there. A file cut short at 40% is missing 60% of the video, and no tool can invent what was never written.

Why the repaired file is shorter

Video frames are not independent. A keyframe stands alone, but the frames after it are stored as differences from it — so if a keyframe's data is broken, every frame that leans on it is unusable too, even though their own bytes are perfectly fine. That is why a file with ten broken frames can lose considerably more than ten.

Repairing keeps only the frames that can actually be decoded, and closes the gaps so the result plays end to end instead of freezing where the damage was. The trade is that the output is shorter than the original by however much was dropped. The page tells you that number before you commit, and again on the result.

In the default mode, retained frames are copied without re-encoding. The full decoding check takes time; the optional recovery mode re-encodes the retained video.

**The sound is kept, and it stays in sync.** Closing the gaps means the picture no longer matches a soundtrack of the original length, so the audio is cut along exactly the same boundaries — every kept stretch of picture carries its own stretch of sound, shifted by the same amount. Within a stretch the two are locked together; only at the seams can the audio be off, and never by more than half of one audio packet, which is about ten milliseconds. That is an order of magnitude below what anyone can hear as a lip-sync error.

What this can't do

**A file that won't open at all is out of reach here.** Every MP4 carries an index describing where each frame lives. If that index is damaged or missing — common when a recording stops without being finalised — there is no map to walk, and this page will say so rather than spin. Recovering those needs the original source or a tool that rebuilds the index by guessing at frame boundaries.

**Audio is not checked for damage.** Existing audio packets are copied and trimmed to match the retained video. Damaged or already missing audio cannot be restored by this process.

**Only H.264 and HEVC.** Those are the codecs that store frames with length prefixes, which is what the check reads. MJPEG, MPEG-4 Part 2 and others lay frames out differently — measured with this ruler they would all appear broken, so the page declines instead.

FAQ