Recovered JPEGs are grey, half missing, or blocky: causes and fixes

The grey-bottom JPEG is the signature symptom of photo recovery gone half right. The top of the image decodes normally, then at some row the picture stops and the rest is flat grey, a repeated smear of the last good row, or a block of colored garbage. Occasionally the whole thing is blocky and shifted, as if the picture was sheared. These aren't random. Each look corresponds to a specific kind of damage, and knowing which one you have tells you whether it's fixable.

A JPEG decodes top to bottom, left to right, in 8×8 (or 16×16) blocks. The decoder reads a compressed stream until it either reaches the end-of-image marker or runs out of valid data. Where it runs out is where the grey starts. That single fact explains almost everything below.

The recovery tool wrote fewer bytes than the original photo had. Common reasons: the file was fragmented on the card and only the first fragment was carved; the carver hit its maximum size or a false end marker; the drive returned read errors partway through; or the photo was still being written when the card was pulled. The decoder gets a valid header, valid tables, and a scan that simply ends. Everything after the last decodable block is painted grey.

How to tell: the file is smaller than sibling photos from the same shoot, and the grey boundary is a clean horizontal line. Opening it in Preview shows the top portion normally.

Signature carving finds a JPEG by its start marker (`FF D8 FF`) and ends it at the next end marker (`FF D9`). But `FF D9` is a two-byte pattern that appears inside other data too, including inside the embedded EXIF thumbnail near the top of many camera JPEGs. A naive carver ends the photo at the thumbnail's end marker and you get a file that's only a few kilobytes: the thumbnail, not the picture. Conversely, if the carver missed the real end marker and kept going, the photo has junk appended after the image, which most viewers ignore but some refuse.

How to tell: tiny file sizes (under ~100 KB for a camera JPEG) mean a thumbnail carve. Oversized files that still open are the appended-junk case and are usually harmless.

A JPEG's compressed scan is one continuous stream. If bytes in the middle are overwritten, the decoder loses sync and everything after that point is garbage: shifted, wrong-colored, blocky. Unless the file has restart markers. Many cameras insert `RST0`–`RST7` markers at regular intervals so a decoder can resynchronize after an error. With restart markers, a corrupt patch produces a band of damage and then the picture recovers below it. Without them, damage propagates to the bottom of the frame.

How to tell: a horizontal band of corruption with normal image below it means restart markers are present and the damage is localized. Corruption that starts at one point and continues to the bottom means no restart markers, or damage to the tables at the top that mis-decodes everything.

A JPEG carries its quantization and Huffman tables in segments before the scan data. If those are overwritten, the whole image decodes wrong or the viewer refuses it outright with "file is damaged." The image data may be entirely intact; it's the decoding instructions that are broken.

Preview and Photos on macOS show what they can and stop. They don't repair anything. ImageMagick's `convert` with a fresh output filename will rewrite a JPEG and discard trailing junk, which fixes the appended-garbage case and nothing else. Neither addresses truncation or table damage. If you recovered with PhotoRec, its `paranoid` mode reduces bad carves but can't recover bytes that weren't in the carved range; re-carving with a better tool is often the fix.

The JPEG plugin works through the file segment by segment. Missing or corrupt start-of-image and header segments are rewritten. Corrupt or missing Huffman tables are replaced with the standard tables (which most cameras use anyway), and a damaged EXIF block is validated and dropped if it's blocking the decoder. The scan data is walked honoring restart markers, so a file with a corrupt band decodes past it. Truncated scans get a proper end-of-image marker so viewers open them instead of refusing. Every repair is verified by actually decoding the result before it's offered to you.

For damage the JPEG plugin can't fix, a fallback extracts the largest intact image embedded in the file. That matters most for RAW: a Canon CR2, Nikon NEF, Sony ARW or Fujifilm RAF whose sensor data is truncated still usually carries a full-size or near-full-size JPEG preview near the start of the file, and that preview is often complete when the RAW isn't. The same extraction works on HEIC and TIFF. It's labeled as a salvage, not presented as a clean repair, so you know what you're getting. The repair page explains the tiers.

If the grey photos came from a generic carve, rescan the source with DataRecover Pro before repairing. Its deep scan validates JPEG structure during carving rather than just matching start and end bytes, skips the embedded-thumbnail false end, and enforces a per-format size limit so one bad marker doesn't swallow the next file. On exFAT and FAT32 cards where the directory is still intact, the quick scan reads the original allocation records and recovers files by their real extents instead of guessing, which sidesteps truncation entirely. Recover to a different drive than the card, and don't run this against a card you've shot on since; those blocks are gone. Scan and preview are free, with thumbnails so you can see which photos are whole before paying anything. Download DataRecover Pro.

Grey means the bytes for that region weren't in the file. If they also aren't on the disk (overwritten by later shots, or on an SSD after TRIM) no repair recreates them, and the honest outcome is a cropped image or the embedded preview. Blocky corruption caused by a failing card's controller returning bad reads needs the card imaged first, then repaired from the image. And if the card is physically damaged or unrecognized by every reader, a recovery lab is the next step, not software.