The same photo, written in two orders
A JPEG begins with a short run of markers — segments that carry the settings a decoder needs before it can read a single pixel. The quantization tables (DQT) define the compression steps; the Huffman tables (DHT) define how the bits are packed; the start-of-frame declares the image dimensions. Then a start-of-scan (SOS) marker introduces the compressed image data itself, the long stretch that is the bulk of the file.
The one marker that decides everything about how a file fails is the start-of-frame. SOF0 means baseline: the image is written in full detail, one horizontal strip at a time, from the top down. SOF2 means progressive: the whole image is written at once, but across several passes that go from coarse to sharp. Same photo, same quality, same tables — only the order of the bytes differs. And that order is the whole story when the file is truncated.
Truncation is by far the most common way a JPEG breaks: an interrupted download, a half-finished copy off a failing card, a save that never completed. In every case the front of the file is intact and the tail is simply missing. What that looks like on screen depends entirely on whether you're holding a baseline or a progressive file.
How a baseline JPEG runs out of data
A baseline decoder fills the image from the top, strip by strip, as it reads. Cut the file short and the decode simply stops where the bytes stop: the strips above the cut are complete and correct, and everything below has no data at all.
A truncated baseline JPEG: strips decode top to bottom until the bytes run out, leaving a sharp upper image and a data-less lower band that decoders paint flat gray.
That data-less region is the familiar gray or grey-green band at the bottom of a broken photo — the unmistakable fingerprint of a truncated baseline file. There's a further subtlety: without restart markers(periodic resync points an encoder can insert into the scan), the color encoding drifts as a single error propagates, so damage that isn't a clean truncation can tint the surviving strips. The gray-bottom case, restart markers, and the color-drift failure are dissected inwhy half your JPEG is gray; this guide's point is narrower — that the gray bottom is abaseline symptom specifically.
How a progressive JPEG runs out of data
Progressive writes the same image in passes that span the entire frame. The first pass lays down a coarse version of the whole picture; each later pass adds detail everywhere at once. It's the reason a progressive image on a slow link appears blurry all over and then sharpens, rather than loading top to bottom.
A truncated progressive JPEG: the early passes cover the entire image, so a cut file loses sharpness rather than its bottom — a soft but complete frame instead of a gray band.
Truncate a progressive file and you usually keep the early passes and lose only the final refinements. The result is a complete image that is soft or slightly blocky — a low-resolution version of the whole photo, not a picture with its bottom torn off. For a given amount of lost data, progressive tends to degrade more gracefully: you trade sharpness across the frame instead of losing a whole region. That is a genuine advantage under truncation, though it is not a form of protection against damage landing inside the header or the early passes.
What repair can actually do
Repairing a JPEG is decoding what survived and writing it back as a valid image, plus fixing the small structures that gate the decode. There are two distinct jobs.
When the image data is truncated, repair decodes every strip or pass that is present and produces a clean, openable file of what was there — a sharp partial frame from a baseline file, a soft full frame from a progressive one. It stops at the last valid data rather than letting a decoder smear the error downward, so you get the maximum honest picture and nothing invented past it.
When the header is the problem, the image data can be whole while the DQT or DHT tables that explain it are damaged — and without those tables the file won't decode at all. Repair can sometimes rebuild them, or graft matching tables from a donor: a healthy JPEG from the same camera or export pipeline, whose tables match the broken file's. That single transplant can bring an otherwise-complete image back to life. The three failure classes and the donor technique are laid out in why half your JPEG is gray.
The honest limits
What repair returns is bounded by what the file still contains.
- Pixels never written can't be recovered. The region below a baseline truncation, or the sharpness lost past a progressive one, was never saved. No tool reconstructs it; anything that "fills in" that area is guessing, not recovering.
- A missing header with no donor is a hard case. If the quantization or Huffman tables are gone and no matching file exists to borrow from, the image data can't be interpreted.
- Damage inside the early passes hurts more for progressive.Progressive's grace applies to lost tail data. Corruption landing in the coarse first pass affects the whole frame, since every later pass builds on it.
- A re-saved broken file bakes in the damage. Once a gray band or smear has been saved into a new JPEG, that output is now the truth; work from the original broken file whenever you still have it.
FAQ
What is the difference between a baseline and a progressive JPEG?
They compress the same image with the same math but write it in a different order. A baseline JPEG stores the picture in full detail one horizontal strip at a time, top to bottom, so a decoder builds the final image as it reads. A progressive JPEG stores the whole picture at once but in successive passes — a coarse version first, then refinements that sharpen it — which is why a progressive image on a slow connection appears blurry everywhere and then snaps into focus. You can tell them apart by the start-of-frame marker: SOF0 is baseline, SOF2 is progressive.
Why does a truncated JPEG show a gray area at the bottom?
That is the signature of a truncated baseline JPEG. Because baseline encodes strip by strip from the top, a file cut short simply stops partway down: the strips that were written decode into a normal image, and everything below the cut has no data, which decoders render as a flat gray or grey-green band. The height of the gray tells you how much of the file was lost. This specific failure is covered in depth in the guide on why half a JPEG turns gray.
What does a truncated progressive JPEG look like?
Usually a complete image that is soft or blocky rather than a picture with a missing bottom. Because progressive writes the whole frame coarsely first and refines it in later passes, a file cut short often contains all the early passes and only loses the final sharpening. The result covers the full frame but lacks fine detail — a soft, low-resolution version of the whole photo instead of a sharp top and a gray bottom.
Can a corrupted JPEG be repaired?
Often partially, and honestly so. If the file is truncated, a repair decodes everything up to the cut and produces a valid image of what survived — a sharp partial frame for baseline, or a soft full frame for progressive. If the header carrying the quantization and Huffman tables is damaged but the image data is intact, those tables can sometimes be rebuilt or grafted from a matching donor file so the picture decodes again. What no tool can do is reconstruct pixels that were never written; the data past a truncation is gone.
Related reading:why half your JPEG is gray, and the container-level counterpart for video inhow video files get corrupted.