"Invalid data found when processing input"

An MP4 or MOV file is a tree of boxes (also called atoms). Each box starts with a 4-byte size and a 4-byte type: ftyp declares the brand, mdat holds the raw audio and video samples, and moov is the index — the sample tables that say where every frame lives, what codec decodes it, and at what timestamp. When ffmpeg opens the file it walks this tree. If it cannot find a coherent moov, or a box announces a size that runs off the end of the file, or the bytes where a box header should be are garbage, it stops and reports "Invalid data found when processing input."

Crucially, the heavy data — the mdat with your actual footage — can be completely intact while this happens. The parser fails on the index, not the pictures. That is why the same file that "has no valid data" can be full of perfectly good frames waiting for a container that describes them correctly. This overlaps heavily with the classic "moov atom not found" case: a recording interrupted before the camera wrote its moov leaves exactly this signature.

When the samples survived but the map is broken, the fix is to remux: scan the surviving stream data, reconstruct the sample tables the container needs, and write a fresh, well-formed MP4 around the same footage. No re-encoding is involved, so there is no quality loss — the frames are the original frames, just correctly indexed again. Where the moov is missing entirely, the tool rebuilds it from the structure of the media stream so the player has the frame map it was looking for.

The other frequent trigger is a mismatched extension or an interrupted transfer. A file named .mp4 that was actually saved as a different container, or a clip whose download stopped partway, both make ffmpeg choke on unexpected bytes. The tool checks what the file really is by its box signatures rather than its name, and salvages the portion that arrived. All of this runs in your browser — no ffmpeg install, no command line, and no server ever receives the video.

Rebuilding the container only works when the container is the problem. If the underlying media data itself is destroyed or overwritten — a card that returned zeros, a file mangled by a failing drive, a recording looped over by the camera — there are no good frames to re-index, and no tool can rebuild footage that is not on the disk. Recover the raw bytes from the storage first, then repair.

The other honest non-starter is a file that is not really a video: a document, an image, or a truncated fragment that happens to carry a .mp4 extension. "Invalid data" is literally true there, and no remux can turn a non-media file into a playable clip. When the footage is present, though, the browser-only approach means sensitive recordings — evidence, personal video, unreleased work — are repaired without being copied anywhere. Open the Network tab and you can confirm 0 bytes of the clip are sent.