How video files get corrupted

The usual causes

Interrupted recording: battery dies, the app crashes, the phone overheats, the card fills. The index is never written. This is the most common cause and the most fixable.

Interrupted transfer: the cable gets bumped, the laptop sleeps, a download times out. The end of the file is missing.

Failing or fake SD cards: cheap cards that report more space than they have will silently overwrite your own footage. Cards also wear out. Errors in the middle of clips often trace back to the card.

Ejecting too early: pulling a USB drive while the computer is still writing.

Bad edits: tools that “trim” a file by cutting bytes rather than remuxing it properly.

How to make a corrupt file for testing

Always do this on a copy of a throwaway clip. To simulate an interrupted recording, cut the end off: on Mac or Linux, head -c 50000000 good.mp4 > broken.mp4 keeps the first 50 MB (the index is often at the end, so this usually removes it). To simulate data damage, overwrite a few bytes in the middle with a hex editor.

Both are useful for testing a player or a repair workflow. The first kind should be fully repairable with a reference clip. The second will leave a visible glitch.

Avoiding it

Use genuine cards from known brands, buy from reputable sellers, and replace them every couple of years of heavy use. Keep cameras charged. Use a card reader for transfers, and wait for them to finish. Record screen captures to MKV.

Already have a broken file?

Start with how to repair corrupted video files or open it in our repair tool for a free preview.

Why people corrupt video files on purpose

Developers test players, upload pipelines, and repair tools against broken files. Video teams rehearse their recovery process before a shoot rather than during a crisis. Educators show students what corruption looks like. Testers check that an app shows a sensible error rather than crashing.

All of these are legitimate. What isn’t is sending a deliberately broken file to dodge a deadline or a request. Recipients can usually tell: a file that is the right size but full of zeros, or a clip that breaks at a suspiciously convenient point, looks very different from real-world corruption. It also tends to create more work for everyone than just explaining the delay.

Building a realistic test set

Real-world corruption falls into a few patterns. A good test set covers each of them, so you know how a player or tool behaves in every case. Start with one healthy clip from a phone, 30 seconds long, and make copies. Never work on footage you care about.

Truncated with missing index: keep the first part of the file and drop the end, where the index lives. head -c 20000000 good.mp4 > truncated.mp4. This mimics a dead battery or crashed recorder and is the most common corruption in practice.

Missing header: overwrite the first few kilobytes with zeros. cp good.mp4 nohead.mp4 && dd if=/dev/zero of=nohead.mp4 bs=1 count=4096 conv=notrunc. This simulates a damaged file-system cluster at the start of the file.

Scattered damage: overwrite small blocks in the middle. dd if=/dev/urandom of=glitchy.mp4 bs=1 count=2048 seek=5000000 conv=notrunc on a copy. Repeat at a few offsets. This mimics a failing card.

Wrong extension: rename a healthy MKV to .mp4, or a MOV to .avi. This tests whether software checks content rather than names.

Zero-length file: : > empty.mp4. A good tool should say clearly that there is nothing to repair.

Doing it on Windows

Windows lacks head and dd by default, but PowerShell can do the same. To truncate: $b = [IO.File]::ReadAllBytes('good.mp4'); [IO.File]::WriteAllBytes('truncated.mp4', $b[0..19999999]). To zero a region, read the bytes, set a range to zero in a loop, and write them back.

Alternatively, install Git for Windows, which includes a Bash shell with head and dd, or use a hex editor such as HxD to select and fill byte ranges by hand.

What each test should show

A truncated file should fail to open in most players with a missing-index error. A good repair tool should rebuild it and recover everything up to the cut, losing at most the last partial frame or two.

A missing-header file should fail with an unrecognised-format error. Repair should restore it, perhaps losing the first second until the next keyframe.

A scattered-damage file should play with visible glitches near each damaged offset. Repair should not crash or hang, and should produce a file that plays through.

A mislabeled file should play in players that inspect content. Tools that refuse it based on the extension have a bug worth fixing.

An empty file should produce a clear message, not a spinner or crash.

The real causes, in more depth

Understanding how corruption happens naturally is the best prevention. Interrupted recordings are the top cause because MP4 and MOV write their index last. Fragmented recording formats avoid this and are worth enabling where your camera or software supports them.

Fake-capacity cards are a nasty second. They claim 256 GB but contain 32 GB of real storage, and silently overwrite earlier data once the real capacity is exceeded. Test new cards with H2testw or F3 before trusting them with anything important.

Worn-out cards develop bad cells over time, especially in dashcams and security cameras that write constantly. Use high-endurance cards in those devices and replace them on a schedule.

Unsafe removal still causes trouble despite modern operating systems caching less. Wait for the camera’s activity light and eject drives before unplugging.

Fixing your test files (and real ones)

Once you have a test set, run it through your workflow. For manual repair, see how to fix corrupted MP4 files. To check our tool, open a test file on the repair page and watch the free 15-second preview. Unlocking full repairs costs $9/month or $29/year.

If you are here because a real file broke, the same principles apply. Work on a copy, identify the type of damage, and use the least invasive repair that works.

Simulating corruption in other formats

MKV: truncation is much less damaging than for MP4, because MKV stores data in clusters with their own timestamps. A truncated MKV usually plays up to the cut. To test header damage, zero the first 4 KB, which removes the EBML header and makes the file unrecognisable.

AVI: truncating removes the idx1 index at the end. Many players then refuse to seek, and some refuse to play. VLC will offer to rebuild the index, which is a useful behaviour to test.

MOV: behaves like MP4. Truncate to remove the moov atom.

MTS and TS: transport streams repeat their setup data every fraction of a second, so they are very robust. Truncation and scattered damage both play through with brief glitches.

WebM: like MKV, truncation is mostly harmless. Zeroing the start breaks it completely.

Automating test-file generation

If you test software regularly, script the generation of corrupted files so each run uses the same inputs. A short Python script can read a healthy file and write variants: truncated at 10%, 50%, and 90%; header zeroed; random blocks overwritten at fixed offsets with a fixed seed so results are reproducible.

Keep the healthy source and the generated variants in version control or a test-fixtures folder, with a small README describing each. When your software changes, run it against the whole set and compare results with the previous run.

FFmpeg can also create synthetic healthy sources, so you don’t need real footage: ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -f lavfi -i sine=frequency=440 -t 30 -c:v libx264 -c:a aac source.mp4 produces a 30-second clip with a test pattern and a tone.

Making corruption match real cameras

Synthetic test patterns compress very differently from real footage, and repair tools may behave differently on them. For realistic tests, record short clips on the actual devices you care about: a phone, a GoPro, a drone, a dashcam. Then create the same corruptions from each.

To simulate a real dead-battery failure most faithfully, record a clip and then remove the battery or force-restart the phone while it is still recording. This produces exactly the file structure that cameras leave behind, including any device-specific quirks.

Do this only with throwaway clips and devices you’re comfortable power-cycling abruptly. Modern devices handle it fine, but it is not something to do routinely.

Ransomware, viruses, and corruption

Ransomware encrypts files and often renames them with a new extension. Encrypted videos look corrupted, but no video repair tool can fix them, because the content is scrambled by design. Recovery means restoring from backup or, in some cases, using a decryptor published by security researchers for that specific strain.

Ordinary viruses rarely corrupt videos. When people suspect a virus, the real cause is usually one of the everyday ones above. A full antivirus scan is still sensible if files across many folders break at once.

Where to go next

If you were testing, you now have a realistic set of broken files and know what results to expect. If you were trying to understand how a real file broke, start the fix with how to repair broken video files or open it on the repair page for a free 15-second preview. Full repairs unlock for $9/month or $29/year.

Testing upload and streaming pipelines

If you build software that accepts video uploads, corrupted files are part of normal traffic. Users upload truncated recordings, mislabeled formats, and files that are actually photos or documents with a video extension. Your pipeline should handle all of them gracefully.

Useful behaviours to test: the upload validates content rather than extension; a truncated MP4 produces a clear message rather than a stuck job; transcoding failures are caught and reported; thumbnails don’t crash on files without a keyframe; huge files are rejected before they consume all your disk space.

Run ffprobe on uploads before heavier processing. It is fast, reports format and errors, and lets you reject or route problem files early.

Testing repair tools fairly

When comparing repair tools, use the same set of corrupted files and record the same measurements for each tool: does the output open, how long is it compared with the original, how many decode errors remain, and is audio in sync.

Include files from several devices. A tool that excels on iPhone footage may struggle with GoPro or DJI files, and vice versa. Real-world performance depends on the mix of devices your users have.

Keep the healthy originals so you can compute how much of each clip was recovered as a percentage. That single number makes comparisons clear.

Cleaning up after testing

Label test files clearly, for example with a TEST_CORRUPT prefix, and keep them in a dedicated folder. It is surprisingly easy for a deliberately broken file to end up in a real project or backup and cause confusion months later.

Delete generated files you no longer need, and keep only the scripted generator and the healthy source, so you can recreate the set at any time.

Corruption is common, and usually fixable

If there is one takeaway, it is that most real-world corruption is structural: the video data is fine and only the index or header is wrong. That is why repairs succeed so often, and why a realistic test set should weight truncated, index-less files most heavily. Glitches from failing storage are less common but worth including, because they test how gracefully software degrades.

Why understanding corruption helps you prevent it

Knowing how videos become corrupted is the best way to avoid it. Nearly every case involves an interruption while the file is being written: a dead battery, a removed card, a crashed app, or a computer shut down mid-copy. The video data is written first and the index last, so any interruption leaves a file that looks complete in size but cannot be played.

Prevention is therefore mostly about letting writes finish. Stop recordings deliberately, wait a few seconds before powering off, eject drives before unplugging them, and keep enough free space so the device never runs out mid-recording.

Testing repair tools safely

If you are deliberately corrupting a file to test a repair workflow, always work on a copy. Truncating the end of an MP4 or overwriting its header are common test cases, and both are handled by index rebuilding.