Recovery and repair are two different jobs
The two words get used interchangeably, and the confusion costs people real files, so here is the distinction as plainly as we can state it. Recovery gets back a file you lost: it was deleted, the card was formatted, the drive died, and the bytes have to be found and copied somewhere safe. Repair fixes a file you have: it's sitting right there with a name and a size, but its internal structure is damaged and nothing will open it.
Recovery software is genuinely good at the first job. But its finish line is "bytes retrieved and written to a new file," not "file opens and plays." Whether those retrieved bytes constitute a working video, photo, or spreadsheet is a separate question the recovery tool typically can't answer and doesn't try to. That's why the folder of rescued files so often contains duds, and why the fix for a dud isn't running recovery again; it's repair, the second half of the job. Nothing went wrong with your recovery; it's just not the whole workflow.
Why recovered files are so often broken
When you delete a file or format a card, the data usually isn't erased; the filesystem's records pointing to it are. Recovery software works around the missing records by reading the raw storage and reassembling files from what it recognizes. Every failure mode of recovered files comes from that reassembly.
Files aren't stored in one piece
Filesystems fragment files: a 2 GB video may be scattered across dozens of separate cluster runs, in whatever order free space permitted. The record of that order died with the filesystem. A recovery tool that finds the file's beginning has to make assumptions about where the rest is (usually "keep reading forward"), and on a fragmented drive that assumption stitches in clusters that belonged to something else. The result is a file that's the right size and mostly right content, with foreign bytes spliced into the middle: videos that play then glitch, photos that decode halfway then smear.
Signature carving guesses where files end
Without filesystem records, recovery falls back on carving: scanning for the signatures files start with (every JPEG opens with the same marker bytes, every MP4 an ftyp box) and cutting out what follows. Beginnings are easy; endings are the guess. Many formats have no explicit terminator, so carvers read until the next file signature or a fixed limit. That produces truncated files, files padded with unrelated data, and the telltale batch of recoveries at identical round sizes: a folder of "videos" that are each exactly 1 GB is a carver's cutoff setting, not your footage.
Some of the data was already overwritten
Deleted space is free space, and the drive kept working after the loss. Every write since then may have landed on top of your file's clusters. Recovery returns what's physically present: the surviving pieces of your file, interleaved with whatever overwrote the rest. No second recovery pass and no repair tool can bring back overwritten regions; that data no longer exists anywhere. This is also why the first rule of data loss is to stop using the drive immediately.
Lost names are cosmetic; lost structure is not
Recovered files often arrive as FILE0001.MP4 or f1042883.jpg: names live in the filesystem records, so carved files lose them. That part is harmless. The structural version of the same loss is not: many files depend on internal tables (a video's index, a PDF's cross-reference table, an archive's central directory), and if the recovery missed or misplaced those regions, the file has its content but no working skeleton. These are the most fixable duds in the folder, because rebuilding exactly that skeleton is what repair tools do.
Triage your recovered files in five minutes
Don't judge the recovery by the first file you try. Sort the batch: it tells you what the recovery actually achieved and where repair is worth your time:
- Right size, right type, won't open → repair candidate. A recovered clip at 1.87 GB when you expected roughly 2 GB has very likely got its data; it needs structural repair, and the odds are good.
- 0 bytes → not a file. The tool restored a directory entry with no data behind it. Nothing to repair; only a deeper recovery pass (or the original device) can help.
- Suspiciously uniform sizes → carver artifacts. Ten files at exactly 1,048,576 KB are cut to a setting, not to your data. A repair attempt on one or two will tell you whether real content lives inside, but temper expectations.
- Opens but wrong content → wrong clusters. A "video" showing someone else's thumbnail, a photo that's half a different photo: the carver spliced files together. The valid portion is sometimes salvageable; the rest belongs to another file.
One more honest check before repairing anything: if the recovered file is bigger than a few MB, open it in a hex viewer and scroll. A file that's overwhelmingly zeros came back empty no matter what the size field says.
Format-by-format: what repair can do after recovery
Repair odds after recovery aren't uniform; they follow each format's structure. Two lines of truth per format:
Video (MP4/MOV). The classic recovered-video failure is a missing or misplaced index, and indexes can be rebuilt from surviving stream data, with good odds when the carver found contiguous footage. Spliced-in foreign clusters reduce the salvage to the valid runs. Repair a recovered video →
Photos (JPG). Header and marker damage repairs well: the photo is intact behind a broken front door. Truncation is partial by nature: JPEGs decode top-down, so you get back the surviving upper portion, and the gray zone is data the recovery didn't find. Repair recovered photos →
Excel and Office files (XLSX/DOCX/PPTX). These are ZIP archives of XML parts under the hood, which makes partial salvage realistic: readable sheets and text can be pulled out even when the archive as a whole is broken. Truncated files lose whatever parts were cut off. Repair a recovered workbook →
PDFs. A recovered PDF most often fails on its cross-reference table (the index saying where every object lives), and that table can frequently be rebuilt by re-scanning the objects that survived. Pages whose data is missing are gone; the rest come back. Repair a recovered PDF →
ZIP archives. ZIP keeps its central directory at the end of the file, exactly the part a truncated recovery loses, but each entry also carries its own local header, so the files inside can be extracted individually. Expect "42 of 50 files salvaged" rather than all-or-nothing. Repair a recovered ZIP →
Do repair before you re-run recovery
When the first batch disappoints, the instinct is to scan again with different settings. Resist it: the order matters. Repair operates on the recovered copies sitting on your healthy drive: it reads them, writes new files, and risks nothing. Re-running recovery means more hours of reads against the failing device you rescued them from, and a drive that's dying physically degrades with every pass, and each scan can be the one it doesn't finish. Wring everything out of the files you already hold; go back to the source only for what repair proves unsalvageable, and make that return trip count with one thorough scan. And through all of it, the standing rule: never recover files onto the drive you're recovering from.
For the fuller picture of what repair can and can't rebuild, and the corruption these files had before recovery ever touched them, see how video files get corrupted.
FAQ
Why won't my recovered files open?
Because recovery restores bytes, not guaranteed-working files. When the filesystem's records are gone, recovery software reads raw storage and reassembles files by recognizing their signatures, a process that involves guessing where files end and which pieces belong together. The result can be complete, truncated, padded with foreign data, or assembled from fragments of different files. A recovered file that won't open usually has damaged or incomplete structure, which is exactly what file repair addresses.
Recuva recovered my files but they are corrupted — what now?
First, keep the recovered copies: don't delete them and don't re-run recovery over the same failing drive yet. Then triage: files with a healthy, plausible size are repair candidates; files at 0 bytes or at suspiciously uniform sizes probably came back empty or misassembled. Run the repair-worthy ones through a repair tool for their format. Repair works on copies and is non-destructive, so trying it costs nothing and tells you file by file what actually survived.
Can recovered videos be repaired?
Often yes. Video files recovered without their index are unplayable but structurally simple to fix: the index can be rebuilt by scanning the recovered stream data. Videos recovered with the wrong fragments stitched together are the hard case: repair can salvage the valid parts, but sections that belong to other files are noise, not footage. The deciding factor is whether the recovery software found the right bytes, and a repair attempt is the fastest way to find out.
Why are recovered photos gray or distorted?
A JPEG decodes from the top down, so a photo that comes back incomplete displays its surviving top portion and fills the rest with gray. Distortion (smearing, shifted colors, scrambled bands) means the byte stream was interrupted or contaminated partway: the decoder lost sync where the recovered data stopped matching the original. The gray region is data the recovery didn't retrieve; repair can clean up the file's structure but can't repaint pixels whose data is absent.
Does data recovery software corrupt files?
Reputable recovery tools read the source drive without writing to it, so they don't corrupt anything themselves. What they can do is deliver files that were already incomplete on disk, or assemble fragments incorrectly, which looks like corruption in the output. The genuine risk to your data is elsewhere: recovering files onto the same drive you're rescuing (which overwrites what's left), or repeatedly re-scanning a physically failing drive, which each pass pushes closer to total failure.
Prevention beats both recovery and repair: how to avoid corrupting files on SD cards.