"Not a JPEG file: starts with 0x..."

A JPEG is a stream of markers, each a 0xFF byte followed by a type byte. The file must open with the Start-of-Image marker, FF D8, and end with End-of-Image, FF D9. Between them sit the metadata and table segments — APP0 (JFIF) or APP1 (Exif), one or more DQT quantization tables, a SOF0/SOF2 frame header that declares width, height and components, the DHT Huffman tables, then SOS (Start of Scan) followed by the entropy-coded pixel data.

When libjpeg's jpeg_read_header() runs, its first_marker routine reads exactly two bytes and compares them to FF D8. If they do not match it raises JERR_NO_SOI, whose text is literally Not a JPEG file: starts with 0x%02x 0x%02x — the two hex values are just whatever it actually found. Notice what this means: the decoder never looked at your photo. It rejected the file on its first two bytes. So the message does not tell you the image is destroyed — it tells you the file does not begin the way a JPEG must. That distinction is the whole reason recovery is often possible.

The two hex values in the message are a genuine diagnostic. If they are close to FF D8 but shifted, or if the file is a valid JPEG with garbage bolted onto the front, resyncing recovers it. If they are the signature of a different format, you are looking at a mislabelled file, not a broken JPEG. Common leading bytes:

• 0x89 0x50 — a PNG (‰PNG). The file was saved or renamed as .jpg but is genuinely a PNG; it needs PNG repair, not JPEG resync.
• 0x00 0x00 — often a HEIC/MP4-family file whose ftyp box starts with a length field, or a truncated download that begins in zeroes.
• 0x52 0x49 (RI) — a RIFF container, usually WebP.
• 0x49 0x49 or 0x4D 0x4D — TIFF byte-order marks, typical of camera RAW files.
• 0xEF 0xBB — a UTF-8 BOM: text (an HTML error page, a base64 blob) was saved with a .jpg name.

The most recoverable case is a real JPEG with a garbage prefix: bytes shoved ahead of the true FF D8. This happens constantly — a recovery/undelete tool that prepends its own header, an interrupted download that captured stray HTTP bytes, a card reader that returned junk at the start of the sector, or two files concatenated by a botched copy. The genuine FF D8 is still present a little further in; the decoder just never scanned for it.

The tool does not trust the first two bytes. It scans the buffer for the true SOI — the FF D8 that begins a real JPEG stream — and strips everything before it, so the file starts where libjpeg expects. From there it walks the marker chain forward and re-validates each segment: it checks that APPn, DQT, SOF, DHT and SOS markers are well-formed and that segment lengths are sane, repairing or resynchronising markers that were mangled and re-anchoring the scan that follows SOS.

Then it salvages the entropy-coded scan — the compressed pixel data itself — and writes out a clean, well-ordered JPEG that decoders will accept. The rebuilt file is validated against Apple's ImageIO, the same decoder your Mac and iPhone use, so a file that opens here opens in Preview, Photos and everywhere else. Every byte of this runs in your browser: the photo is read from disk, realigned and re-emitted locally, and you can confirm in the DevTools Network tab that zero bytes are uploaded — which matters when the image is personal, evidentiary or not yet published.

Resyncing only helps if there is a JPEG to resync to. If the message reports the signature of another format — 0x89 0x50 for PNG, a RIFF/TIFF/HEIC mark — then the file is not a JPEG at all, and no amount of JPEG repair changes that. It may still be a perfectly good image in its real format (try JPEG repair only after confirming it is one), but a PNG has to be treated as a PNG. Renaming a file never changes its bytes, and neither can we.

The second hard limit is truncation. If the scan after SOS was cut short — a download or card copy that stopped partway — the top of the image is recoverable but the rows past the cut were never written; they come back as gray or repeated blocks, and no tool can invent pixels that were never saved. Finally, if the quantization or Huffman tables are missing or corrupt beyond reconstruction, or the entropy data itself is genuinely scrambled rather than merely misframed, the scan cannot be decoded — realigning the container does not regenerate destroyed compressed data. This is the honest ceiling: we fix how the file is framed and salvage what was actually recorded; we do not fabricate image content.