Photo Repair: Grey, Half-Loaded or Unopenable Photos

About the Photo Repair: Grey, Half-Loaded or Unopenable Photos

A photo that opens half grey, shifts colour part way down or will not open at all is usually not lost: the picture data is in the file, and the part that tells a viewer how to read it is damaged — or the last part of the file never arrived. This page works on the file’s own structure, never on guesswork.

For a JPEG it re-reads the markers, writes back a missing end marker and drops rubbish before the start. When the start of the file was overwritten, it finds the photo’s own tables further in — a camera writes them after tens of kilobytes of metadata — and writes a new start in front of them, without mistaking the small preview inside that metadata for the photo. Only when the tables are gone too does it take them from a healthy photo the same camera took in the same mode, and then nothing else of that photo: not its date, camera settings or location. For a PNG it checks the eight signature bytes and every chunk checksum, undoes the damage a text-mode transfer does, and unpacks the image data as far as it goes, writing the rows that were really there into a new, valid file. A photo with nothing wrong in its structure is reported as such, never “repaired”. For a HEIC photo it decodes whatever decodes, through the same decoder the rest of this site uses. And for any photo, including RAW files from a camera, it finds the complete pictures stored inside — the full-size preview a camera writes beside its RAW data, or the preview in a photo’s metadata — which often survive when the main picture does not. Nothing is uploaded.

Common uses

• Photos that came off a memory card after a card error, a camera crash or a battery that died mid-write.
• Photos copied from a card that disconnected part way through.
• Photos found by a deep scan of a disk image and marked partly damaged.
• Photos whose first sectors were taken by another file, so no viewer opens them.
• PNG screenshots and exports damaged by a text-mode transfer.
• RAW files that will not develop, when the camera’s own preview is good enough.

What a repair can and cannot put back

A photo is a header (what size it is, which tables decode it) followed by compressed picture data. The header is small and easy to lose, and it can be rebuilt or borrowed. The picture data cannot: bytes that are not in the file cannot be worked out from the ones that are, because every part of it depends on the part before.

So a repair makes a file open, and shows all of the picture that reached the card. Below the point where the data stops, a JPEG stays grey or colour-shifted and a PNG is filled with an even grey. That is the truth about the file, not a failure of the repair — and it is why the page shows you the result before anything is saved.

How a PNG is checked

PNG was built to be checkable, and this page uses what it provides. The eight signature bytes at the start exist so that a damaged transfer is spotted at once, and every chunk carries a CRC-32, where a mismatch means the data or the checksum was corrupted in transit (W3C PNG specification). The specification names the three kinds of damage: a transfer in text mode, in which byte codes 13 and 10 are added, removed or converted throughout the file; an unexpected end, in which the file is truncated; and a storage error, in which whole blocks hold random values (PNG error handling).

• Text-mode damage is read straight off the signature. Where a carriage return was added in front of every line feed, taking them out again restores the file exactly, and the chunk checksums prove it. Where the transfer went the other way and those bytes were deleted, the file cannot be restored — the page says so and tells you to copy it again in binary mode.
• Wrong checksums of the chunks the picture needs are recomputed, so a strict viewer opens a file whose picture data is actually fine; the image data’s own checksum (Adler-32) is checked as well. A metadata chunk whose checksum is wrong is left out instead, because its contents may be what was damaged.
• A truncated file is unpacked as far as it goes, and the rows that came out whole go into a new, valid PNG of the original size, with its end marker in place.
• Other chunks follow the specification’s rules for editors: known ones and those marked safe to copy are kept, on the same side of the image data as before; unknown ones marked unsafe to copy are left out whenever the image data had to be written again, as the specification requires (PNG editors). When the image data is complete, it is kept byte for byte.

The picture inside the picture

Cameras store complete JPEG pictures inside their files: a thumbnail and often a full-size preview in a photo’s metadata, and in a RAW file a full JPEG of the developed picture beside the sensor data. Each one is a working photo on its own, and they sit at different places in the file, so damage that ruins one often leaves another untouched.

The page lists every complete picture it finds, with its pixel size and whether it is the camera’s full-size preview, a smaller one or a thumbnail, and each one can be saved as it is: nothing is re-encoded, so it is exactly the JPEG the camera wrote. A picture is listed only when its own structure is complete and a browser can decode it.

HEIC and AVIF photos

HEIC and AVIF keep one compressed picture, laid out as tiles inside a container, with none of the row-by-row structure a page can rebuild. So there is nothing to repair in the picture itself: the page reads the container, decodes every picture it holds with the same decoder the rest of this site uses, and saves what came out as a PNG, which loses nothing. Where the container holds a second picture or a preview, that is tried too, which is often what saves a damaged file a modern camera or mobile wrote.

What cannot be done: a HEIC whose picture data is damaged in the middle is lost, because the rest of its tiles depend on the part that is gone.

What the repair is measured against

The page’s automated tests build photos in code and break them the way cards and bad copies do: a JPEG cut short, a JPEG with rubbish in front of its start marker, a camera JPEG whose first sector was overwritten (with and without its tables, with its small preview still inside), a JPEG whose tables are damaged or gone and are transplanted from another photo, a PNG with a damaged checksum, a PNG whose image data stops part way, a PNG stretched by a text-mode transfer, and files holding embedded previews of several sizes. Every repaired file is read back and checked: a JPEG must end with its end marker and keep its original picture data byte for byte, and a PNG must have correct checksums, the original pixel size, and the rows that were in the file in the right places. Healthy photos, including ones with a second picture after their end marker, must come back as needing no repair.

No success rate is published for other people’s photos: how much comes back depends only on how much of the file reached the card.

Limitations

• JPEG, PNG, HEIC, AVIF and RAW files are handled. PSD, AI, EPS, SVG, WebP, GIF and BMP are not repaired here.
• Missing data stays missing. Below the point where the picture data stops, a JPEG stays grey or colour-shifted and a PNG is filled with grey; nothing is painted in.
• A photo whose own tables and header are gone needs a reference photo from the same camera at the same pixel size, in the same orientation and the same mode. When its scan header is gone too, the first rows and the overall colour can be off.
• An interlaced PNG is repaired only when its image data is complete (its checksums, signature or end marker were the damage). One that is cut short cannot be rebuilt row by row: its rows are spread over seven passes.
• A JPEG variant no browser decodes (a lossless or arithmetic-coded JPEG, as in some medical and scanner files) cannot be shown or rebuilt here; its embedded preview may still be there.
• HEIC and AVIF cannot be repaired inside the picture data, only decoded as far as the decoder manages, and the result is saved as a PNG rather than as HEIC.
• There is no “AI” step here. A tool that paints in missing parts of a photo is a different thing from a repair, and this page never calls one the other.
• A web page cannot set a file’s date, so a saved photo carries the date it was written. The date the photo was taken stays in its metadata.

Privacy

The photo and the reference photo are read by your browser on your device; nothing from either of them is sent anywhere, and the page works offline once it has loaded. The HEIC decoder is downloaded from this site once, then works offline too.