Fix it now
- Drop the file
- Repair runs locally
- Download the result
What Error -2048 actually means at the byte level
Both .mov (Apple's QuickTime File Format) and .mp4 (the ISO Base Media File Format it inspired) store everything as a sequence of atoms: a 4-byte size, a 4-byte type tag, then the payload. A healthy file opens with an ftyp brand box, carries the actual audio/video bytes in a large mdat ("media data") atom, and describes them in a moov ("movie") atom. The moov is the table of contents — inside it, trak → mdia → minf → stbl holds the sample tables (stsz sizes, stco/co64 chunk offsets, stts timing, stss keyframes). Without those tables, QuickTime has a blob of bytes and no map, so it cannot even begin: hence -2048.
Three real situations produce this exact error. The moov atom was never finalised. Cameras, phones and screen recorders buffer the sample tables in memory and write the moov last, on a clean "stop". If the app crashed, the battery died, or the card was pulled mid-write, the mdat is on disk but the moov was never flushed — the classic "moov atom not found". The moov is present but mis-placed, or its offsets no longer match after a bad transfer or partial "fast-start" rewrite, so QuickTime reads garbage where a sample table should be. Stray bytes sit before the ftyp box — an HTML error page saved with a .mp4 name, a concatenation artefact, or a corrupted download prefix — so the very first atom header is invalid and the parser rejects the file outright.
How the container is rebuilt in your browser
The repair works purely on the container, never re-encoding your footage. First it resynchronises to the real start of the file: it scans forward, discards any stray bytes sitting before the ftyp box, and finds the first valid atom header. Then it walks the atom tree to see what survived. If a usable moov exists but its chunk offsets are wrong, it re-anchors them to the real positions of the mdat data. If the moov is missing entirely, it reconstructs the sample index by scanning the mdat payload directly — reading the H.264/HEVC NAL units or the frame boundaries of the stored streams, rebuilding the stsz/stco/stts/stss tables QuickTime expected, and wrapping them in a fresh, well-formed moov.
The result is a stream-copy remux: the original video and audio samples are lifted out and placed into a clean container with a valid header. Nothing is transcoded, so there is no quality loss and no waiting on a codec — the picture that was recorded is the picture you get back. Because the streams themselves are untouched, a clip that only had a broken map typically plays start-to-finish afterwards in QuickTime, VLC or a normal video player. All of this runs in the browser tab: the file is read from your disk and rebuilt locally, so you can open DevTools, watch the Network panel, and confirm that 0 bytes of your video leave the machine.
When a healthy reference clip helps
Rebuilding a moov from scratch means reproducing the exact codec configuration the broken file no longer carries — the parameter sets a decoder needs to interpret the stream (the SPS/PPS for H.264, or the VPS/SPS/PPS for HEVC), the frame rate, the resolution and the audio layout. When those details were only ever stored in the lost moov, the safest way to recover them is from another clip that shares them.
That is why the repair may ask for a short, healthy clip from the same camera or phone, shot in the same mode. It reads the working file's configuration and applies it to the rebuilt index, so the recovered movie reproduces the original rather than approximating it. Match the source: an HEVC reference for an HEVC recording, H.264 for H.264, and ideally the same device and settings that produced the broken file. You are only prompted for a reference when the repair genuinely cannot infer the configuration on its own; when a valid moov survived, none is needed.
The honest ceiling — what -2048 repair cannot do
This repair fixes the map, not missing footage. If the recording was truncated — it stopped before the last frames were ever written to mdat — those bytes do not exist anywhere, and no tool can invent them. You get back everything up to the cut, cleanly playable, but not a single frame past it. That is the real limit, and it is the same for QuickTime's own recovery, professional software or ours.
A few other cases are genuinely out of scope. If the mdat payload itself is scrambled or partially overwritten — not just unindexed, but corrupted inside — the samples cannot be trusted and rebuilding the header will not restore clean playback. A pure codec gap (a stream QuickTime lacks the decoder for) is not a container problem, so a valid moov will not make it play; that is a different error, not -2048. And renaming a file to .mov or .mp4 does not make it one — if the bytes were never a QuickTime/ISO container, there is no index to rebuild. When the container is the problem, though, -2048 is one of the most recoverable video errors there is, because the footage was usually there the whole time.
What this can and can't fix
Can fix
- A .mov/.mp4 whose moov atom was never finalised because the recording stopped uncleanly
- A file with stray bytes before the ftyp box (bad download, wrong prefix, concatenation artefact)
- A present-but-broken moov whose chunk offsets no longer match the mdat data
- Rebuilding the sample index (stsz/stco/stts/stss) by scanning an intact mdat payload
- A clean stream-copy remux into a valid container with no re-encoding or quality loss
Can't fix
- Frames past a truncation — footage the recording stopped before ever writing cannot be invented
- An mdat whose media bytes are themselves scrambled or overwritten, not merely unindexed
- A missing-moov rebuild with no matching reference clip when the codec configuration is unrecoverable
- A file that was never a QuickTime/ISO container in the first place (a rename alone), or a 0-byte file
If a repair fails, we tell you why (missing data versus broken structure), and you are never charged for a failed repair.