IntactFile

Fix "moov atom not found" — rebuild the index in your browser

The error means the file's index was never written. Your frames are still in the file; they just have no map. Maps can be rebuilt.

Your file never leaves your device — repair runs in your browser. 0 bytes uploaded.

Your data is the big block — usually intact. What breaks is the small index. Repair rebuilds it.

Drop a file here or browseTap to choose a file

ZIP · Office · PDF · video · JPG · PNG · RAR/7z · SQLite — repaired right here in your browser. Nothing is uploaded

0 bytes uploadedFree: 3 repairs/day — up to 500 MB video, 100 MB docs & archives, 50 MB photos. Free download. Single repair €5.90. No account required.

Short answer

IntactFile diagnoses and repairs "moov atom not found" MP4s in your browser — drop the file and it runs entirely on your device, with 0 bytes uploaded (open the Network tab and watch: no request carries your video off the machine). It fixes files today when the moov atom survived in damaged, truncated, or mis-offset form, rebuilding a working index for your frames with nothing to install. The honest limit: reconstructing the index for a file with no moov atom at all is still in development — if yours is missing entirely, untrunc is the current recommendation.

Repair the file now

  1. Drop the file
  2. Repair runs locally
  3. Download the result

Drop the MP4 above. The tool reads it locally and reports whether the moov is damaged or absent entirely, which decides the repair path. Nothing is installed and nothing is uploaded.

Where the engine stands, honestly: the structural remux repair (for files whose moov exists but is damaged, truncated, or mis-offset) runs today. Full index reconstruction for files with no moov at all is in development.

What the error means

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x...] moov atom not found Invalid data found when processing input

An MP4 stores your compressed frames in one large block (the mdat atom) and, separately, the moov atom: the index that records where every frame starts, how long it lasts, and how audio and video interleave. The moov is written when recording is finalized, because frame sizes and counts aren't known until encoding ends. A crash, power cut, or full card before that moment leaves the data block on disk and the index nowhere.

That's why the second ffmpeg line says invalid data: the demuxer isn't reporting destroyed footage, it's reporting that it has no index to interpret the footage with. Different problem, and a far more fixable one.

Why ffmpeg can't fix this

If you're here, you've probably already tried ffmpeg -i broken.mp4 -c copy out.mp4 and maybe -movflags faststart. Both failed for the same reason: they operate on the output of a successful read. Stream copying needs the demuxer to hand it packets; faststart relocates a moov that must already exist. When the input has no moov, the read fails before either flag matters. This isn't a flag you haven't found; it's a genuine boundary of what a converter can do. Fixing the file means reconstruction, not conversion: scanning the raw data block for frame boundaries and rebuilding the sample tables from what's found.

vs. untrunc — and where our engine stands

untrunc is the established free tool for exactly this reconstruction, and it works. The friction is real, though: you compile it yourself (or trust a third-party build), run it from the command line, and it requires a reference file: a healthy recording from the same device with the same settings, used to interpret the raw frames in the broken file.

Our position, stated plainly: IntactFile's in-browser engine performs structural remux repair today: files whose moov survived in damaged form. The untrunc-class reconstruction of a file with no moov is in development, and we won't pretend it ships before it does. If your moov is missing entirely and you need the fix this minute, untrunc is the honest recommendation; if the diagnosis above shows a damaged-but-present index, the browser repair handles it now — no compiling, no reference hunt, no upload.

What this can and can't fix

Rebuilding an index, by any tool, works when the media data survived. It usually did: mdat is written continuously during recording, so everything up to the interruption is physically in the file. What no software can do is repair a file whose data was never written. The tell is size: an "hour-long recording" occupying 12 KB, or a file that reads as mostly zeros because the SD card died mid-write, has nothing inside to index. Check the size against the recording length before spending time on any tool — ours or anyone's. And a failed repair is never charged.

FAQ

How do I fix moov atom not found with ffmpeg?

You can't — not with ffmpeg alone. ffmpeg's demuxer needs the moov atom to interpret the input, so every recipe built on reading the file (-c copy, -movflags faststart, re-encoding) fails at the same wall. Fixing the file means reconstructing the index from the raw media data, a different class of tool: untrunc on the command line, or the repair IntactFile is built for.

Can ffmpeg recover an MP4 without a moov atom?

No. ffmpeg is a converter, not a reconstructor: it transforms files it can read, and a moov-less MP4 is unreadable to its demuxer. Its one use here is diagnosis: the error confirms the index is missing while saying nothing about the media data, which usually survived.

What causes moov atom not found?

The recording was never finalized. The moov atom is written when recording stops cleanly, so a crash, power loss, full disk or SD card, or a killed app leaves the data on disk with no index. The same error also appears when a download or transfer was cut short, because the moov commonly sits at the end — the part that never arrived.

Does untrunc need a reference file?

Yes. untrunc requires a healthy video recorded by the same device or software with the same settings. It reads the codec parameters and structure from that reference to make sense of the raw frames in the broken file — without a matching reference, it can't interpret the data it finds.

Is the video data still in the file if the moov atom is missing?

Usually, yes — the media data is written continuously while you record; only the index is deferred to the end. Sanity-check the size: if it roughly matches the recording length (a few GB for an hour of 1080p), the frames are almost certainly there. A file at 0 bytes or a tiny fraction of the expected size has nothing left to repair.

Same error, specific source:OBS crashed mid-stream ·GoPro lost power while recording ·drone battery died mid-flight ·any other MP4 damage