Why half your JPEG is gray

How a JPEG is built: a rulebook, then the scan

A JPEG is two parts sharing one file. The first is a short header: a set of markers that carry the rules a decoder needs before it can draw anything. The frame marker (SOF) records the image dimensions and how many color components there are. The quantization tables (DQT) say how aggressively the file was compressed. The Huffman tables (DHT) are the codebook for unpacking the compressed values. Together these are the rulebook.

The second part is the entropy-coded scan: one long, tightly packed stream of the actual pixel data, which usually makes up almost the whole file. It is read in strict order, block by block, from the top-left corner to the bottom-right. The decoder cannot skip ahead and cannot start in the middle, because each block builds on the one before it.

A JPEG in two pieces: a small rulebook up front, then the long scan of pixels the rules explain how to read.

That split explains every symptom below. Damage the rulebook and the decoder can't begin, even when every pixel is present. Cut the scan short and the decoder draws what it can, then stops where the data stops.

Three failure classes, and what each one means

Corrupted photos fall into three recognizable classes. Matching your symptom to its class is the fastest way to know the prognosis before you spend any time on a fix.

Class 1: it won't open at all

Every viewer refuses the file, or shows a broken-image placeholder. This is almost always header or marker damage: the rulebook up front is mangled, so nothing can start reading the scan behind it. Counterintuitively, this is the class with the best odds, because the image data is usually sitting there intact behind a broken front door.

Class 2: top fine, bottom gray or smeared

The photo opens, the upper portion looks perfect, and then it drops to flat gray or a downward smear of the last good line. This is truncation, or a bit error partway through the scan. Only the part above the cut still exists. This is a genuine partial: you get the real top back, and the gray below is gone.

Class 3: it opens, but the colors are wrong

The whole image displays, but it is posterized, tinted, or color-shifted. Here the scan is intact and it is the tables steering it that are wrong: a damaged DQT or DHT decodes real pixels with the wrong rules. Because the picture data survived, correcting or replacing the tables often brings the colors back cleanly. The three classes above are exactly the buckets the photo repair tool sorts a file into when it reads it locally.

Why the bottom goes gray and stays gray

A JPEG decodes top-down, block by block, and each block's brightness is stored as a difference from the block before it. That running dependency is why the decoder has to move in order and can't jump to the bottom of a damaged file to rescue it. When the scan ends early, a truncated download or a card pulled mid-write, the decoder simply has no more blocks to draw. Most viewers fill the remainder with neutral gray; some repeat the last value they read, which looks like a vertical smear.

Truncation, drawn: the rulebook and the top of the scan survived; the rows below the cut were never in the file.

The gray area is not hidden, encrypted, or waiting to be unlocked. It is image data that does not exist in the file, so no tool can bring it back: restoring it would mean inventing pixels, and inventing pixels is not repair. A single flipped bit in the middle of the scan produces the color-shift version of the same story. It knocks the compressed stream out of sync, and everything after that point decodes as noise until a restart marker (RST), if the camera wrote any, lets the decoder recover. Many cameras don't write them, which is why one bad byte can ruin the lower two-thirds of a frame.

The Photoshop marker error, decoded

If you have opened the file in Photoshop, you have probably seen this, verbatim:

Could not complete your request because an unknown or invalid JPEG marker type is found.

Photoshop is the strictest reader in the room: it validates every marker and refuses the whole file if one is wrong. That strictness is actually useful for diagnosis. Open the same file in a browser or in Preview first. If the picture shows up there, the scan is fine and the damage is confined to the markers, class 1 or class 3, the best odds you can get. Windows Photos phrases the same underlying problem as It looks like we don't support this file format. and Preview on the Mac tends to say the file may be damaged. Different wording, same question underneath: is the rulebook broken, or is the picture gone?

Salvage tactics: donor headers and the EXIF thumbnail

When the damage is in the header and the scan behind it survived, the classic manual fix is a donor-header transplant. You take a healthy photo shot on the same camera at the same settings, copy its header, and graft it onto the broken file's orphaned scan. Same camera and same settings means the same quantization and Huffman tables and the same frame dimensions, so the borrowed rulebook fits the stream it now has to describe, and the image decodes again. It is fiddly, byte-level work by hand; structural repair tools automate exactly this class of fix. The honest caveat: it only works when the scan really is intact and the dimensions match. A donor from a different resolution or a different camera model will not line up, and forcing it produces garbage.

When the main scan itself is gone, one option is left. Most camera and phone JPEGs embed a small thumbnail, its own complete little JPEG a few hundred pixels wide, inside the EXIF metadata at the front of the file. If the header survived but the main image did not, that thumbnail may be the only whole picture you can pull out. It is low resolution and it is a salvage, not a restore, but for a photo that is otherwise gray below the first inch, a clean postage-stamp version can be better than nothing. Many broken photos arrive this way from data recovery software, where a carved file often keeps its header and thumbnail while the scan is only partly there.