Verify recovered files before you format, move, or reuse the card, because the failure this prevents is the worst one in the process: discovering three days later that half of what you “recovered” will not open, on a card that has already been wiped and refilled. Recovery software reports what it wrote, not what is intact. Those are different numbers, and the gap between them is what this page exists to close.
The procedure below takes ten minutes to an hour depending on volume and ends with one answer: is this card safe to return to service, or does it need a second recovery pass?
The Rule Before Any Verification: Do Not Format the Card
The recovered files live in a folder somewhere. The card still holds the original data. Until verification is finished, both copies exist and neither is expendable, so formatting the card now destroys the only remaining evidence if a file did not come back the first time.
Keep the card out of service, and make a sector-level image of it first, so a second attempt never depends on the original. The reasoning is in the guide to cloning a card before recovery.
Recover to a drive with a different letter than the card’s, so nothing can be written back to the source.
Step 1: Reconcile File Counts and Total Bytes
Start with arithmetic, not playback. Count the recovered files, then compare that count and the total byte volume against what the card should hold.
| Comparison | What it catches | What it misses |
|---|---|---|
| File count against the camera’s running number | Wholesale gaps, missing ranges of frames | Individual truncated files |
| Total bytes against used space on the card | Broad shortfalls from an incomplete scan | Size inflation from padding |
| Files per folder against the DCIM structure | Files recovered without their original folders | Files placed in the wrong folder |
| Smallest and largest file in the set | Zero-byte entries and files far too small | Rare, genuinely small files |
Camera filenames run in sequence, which makes this check unusually powerful: if the recovered set holds 4,100 continuous entries out of a sequence that should reach 4,820, the missing 700 were probably never scanned rather than never written. Holes at specific points, by contrast, were likely overwritten and should be treated as permanently gone.
Zero-byte and suspiciously small files should be written off immediately: a 12 MB photo that recovered as 4 KB is a directory entry with no data behind it. If counts fall far short, run a signature-based deep scan as well, since it finds files whose directory entries are gone.
Step 2: The Batch Thumbnail Scan
Set the recovered folder to large-icon view and scroll. This is the fastest triage available and it catches the most common failure: visually perfect thumbnails attached to broken payloads.
Here is where intuition breaks. A thumbnail is often not decoded from the image data at all. RAW formats, and many JPEG and HEIC files, embed a small preview inside the file so cameras and editors can display something instantly. A RAW file can show a flawless thumbnail from that embedded preview while its main payload is truncated and undecodable. The file looks recovered and is not.
The reverse happens too. A photo that refuses to open may be entirely intact, with a damaged header rather than damaged image data. Files that will not open after recovery are frequently a repair problem rather than a data problem.
| Thumbnail state | Likely meaning | Next action |
|---|---|---|
| Renders correctly and opens in a viewer | Probably intact | Spot-check a sample at full size |
| Renders but will not open | Damaged header or container | Try the embedded preview, then a repair pass |
| Gray blocks across part of the frame | Partial data loss in that region | Keep it; the intact regions are usable |
| Gray blocks across the whole frame | Payload not recovered | Retag as failed and rescan |
| Black or blank in RAW only | Preview embedded, payload damaged | Extract and keep the preview at minimum |
Scroll the entire set rather than sampling the first screen, because files lost in one write event usually sit together in the folder.
Step 3: Video Integrity by Frame Extraction
Video needs a different test, because a truncated clip frequently presents as a complete one. Container headers store a duration value written when recording began, so a file can report 12 minutes and stop decoding at 3. Duration metadata is a claim, not a measurement.
Extract frames instead. Point a tool at the recovered file and pull frames at intervals across its full length, then open a few. Frames that decode cleanly across the whole span mean the clip is intact. Frames that turn gray, green, or freeze at a consistent point mark where the data ends. Audio belongs in the same pass: a clip whose audio leads or trails the picture by a fixed fraction of a second has a timestamp problem that a remux usually corrects, while a drift that grows across the clip does not.
The most valuable single test for an unplayable clip is to check whether its index is present. Files that will not play after recovery are usually complete payloads with a missing or damaged index atom, which is a repair job rather than a lost take. Clips interrupted by a camera shutdown, a crash, or a card removal have exactly that profile, and rebuilding the index with a reference clip from the same camera and recording mode is a well-understood operation.
Step 4: Hash Comparison, and Where It Stops Helping
Checksums are the strongest integrity tool available and the most commonly misapplied. A hash proves that two files are byte-identical. It does not prove that either file is correct.
That distinction matters here. Hashing a recovered file against the card is impossible once the directory entry is gone, because there is no original left to hash against. Hashing the recovered set against a sector-level image does work, and it is the correct way to confirm that a copy made after recovery is faithful. What a hash cannot tell you is whether the bytes form a complete photograph, because a truncated file hashes perfectly against itself.
| Method | Proves | Does not prove |
|---|---|---|
| Count and byte totals | Coverage of the scan | Integrity of any single file |
| Thumbnail rendering | That a preview exists | That the payload decodes |
| Frame extraction | That the payload decodes across its length | That the audio is in sync |
| Hash against the card image | That the copy is faithful | That the source was ever complete |
Hash to protect the copy, open files to confirm content, extract frames to confirm footage.
Step 5: Metadata, Timestamps, and Sequence Gaps
Metadata turns a folder of files back into a shoot. Check that capture timestamps are present and ordered, that camera and lens data survived, and that files fall inside the date ranges you expect.
Then look for sequence gaps. Fifty consecutive missing frames matter far more than fifty scattered ones, because consecutive loss points to a single write event such as a card pulled mid-buffer, while scattered loss points to overwrite or wear. Files recovered without metadata still hold usable image data but sort to the wrong place. Rebuilding photo metadata is far easier while the card image is still available.
Corrupt metadata is also a signal about what to trust: a photo with intact EXIF and a clean decode is safe to deliver, while one that decodes without metadata is usable but should be flagged, because its place in the sequence is a guess.
The Verification Log, and When the Card Is Safe to Reuse
Write the result down, even on a small job: a short log lets a client question be answered with evidence rather than recollection.
| Field | Example | Why it matters |
|---|---|---|
| File range | IMG_1200–IMG_1480 | Shows exactly which part of the shoot survived |
| Verified / expected count | 268 of 281 | Quantifies the shortfall without guessing |
| Failed files and suspected cause | 13 files, interrupted write | Separates repairable from unrecoverable |
| Repair attempted and outcome | 9 repaired, 4 unrecoverable | Records what was tried before declaring loss |
| Card decision | Returned to service / retired | Stops a suspect card re-entering rotation |
The card goes back into service only if verification came back complete, or if the shortfall is understood and accepted. A card that produced truncated files after a clean recovery has demonstrated a fault, so test it before trusting it with paid work. When a file is genuinely gone, the correct move is to say so and stop; the criteria for deciding that data is unrecoverable are worth applying early rather than after a week of passes.
Drone and action camera operators face the same steps with more emphasis on batch decoding, as documented in verifying recovered drone footage.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
Frequently Asked Questions
How do I know a recovered file is really complete?
Open it in the application you intend to use it in, and for video extract frames across the full length rather than trusting the reported duration. A file that renders, plays, and carries intact metadata has passed the tests that matter in practice. A thumbnail alone proves nothing, because it may come from an embedded preview.
Can I format the card immediately after recovery finishes?
Not until verification is complete. Keep the card untouched until every recovered file has been checked, so a second scan is still possible if something failed. Once the verified set exists on a separate drive, ideally in two places, the card is disposable.
Why did some files open and others not, from the same scan?
Files written in the same event tend to fail in the same way, but a card usually contains several events. Deleted files, files in a broken directory, and files damaged by an interrupted write come back through different paths, which is why a mixed result is normal.
Is a hash check worth doing on every file?
For archival copies, yes. For a consumer recovery set, a hash of the recovery folder against a post-recovery copy is enough. Hashing against the card itself is only meaningful if you kept a sector-level image, since there is otherwise no original file left to compare against.