Find what's broken in a video, then repair it

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.

What this page actually checks

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.

That is the single thing this page measures, frame by frame, for the whole file. It is also why it can tell you *where* the damage is rather than just that the video won't play: each broken frame has a position and a timestamp, so the damage can be drawn on a timeline.

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.

This check needs no video decoder, which is why it works on files your browser can't play. It reads bytes, not pictures.

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.

Nothing is re-encoded. Frames that survive are copied byte for byte, so the picture quality of what's left is exactly the original — and the whole thing finishes in seconds rather than minutes.

**The repaired copy has no audio.** Closing the gaps is what makes the result play smoothly, but it also means the picture no longer lines up with a soundtrack that still has its full original length — every dropped stretch would push the two further apart. A video whose sound drifts further out of sync the longer you watch is worse than one with no sound at all, so this tool writes the picture only. If the audio in your file is intact and that's the part you need, the extract-audio tool pulls it out separately.

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.

**Damaged audio isn't covered.** Finding a bad audio packet means running it through a decoder, which is a different and much slower job than reading length prefixes. A video whose picture is perfect but whose sound is broken will come back from this check looking clean.

**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

Is my video uploaded anywhere?

No. The file is read by your browser on your own device, and the repaired copy is written there too. Nothing is sent to a server — you can confirm it by opening your browser's network panel while the scan runs, or by disconnecting from the internet first.

Will repairing reduce the quality?

No. Frames that survive are copied exactly as they are, with no re-encoding, so what remains is bit-for-bit the original picture. What you lose is duration, not quality.

Does the repaired file still have sound?

No — it contains the picture only. Repairing closes the gaps left by dropped frames, which shortens the video, and a soundtrack kept at its original length would drift further out of sync with every gap closed. Silent-but-watchable beats progressively-out-of-sync. If the audio is the part you need and it's intact, extract it from the original with the extract-audio tool.

The scan says the file is intact, but it still won't play. Why?

This check covers the picture data of H.264 and HEVC video. A file can pass it and still fail to play for other reasons: a codec your player doesn't support, a damaged audio track, or a container quirk. A clean result here narrows the problem down rather than closing it.

How long does the scan take?

Every frame has to be read, so it scales with file size rather than duration. On a normal machine the scan runs at a few hundred megabytes per second, which puts a one-gigabyte file at a handful of seconds. You can cancel at any point.

Can it recover the part of a video that was never downloaded?

No. If a transfer stopped early, the missing picture data was never written to your disk — there is nothing on your device to recover. What this page can do is tell you exactly how much is missing, and write out a clean, playable copy of the part that did arrive.

My file won't even open. What now?

That points at the file's index rather than its frames, and it's the one case this page can't help with. Try to obtain the original again if that's possible. Failing that, a dedicated recovery tool that rebuilds the index by scanning for frame boundaries is the next step — the Mac app can also re-encode around damage that a browser can't.