← Blog

The thumbnail inside the photo — the leak everyone forgets

EXIF carries a second JPEG inside the first — a 160×120 thumbnail in IFD1 EXIF block (the TIFF inside APP1) IFD0 — main image metadata Make / Model / DateTimeOriginal / Orientation ExifIFD pointer → SubIFD with FNumber, ISO, etc. GPSInfo pointer → GPS IFD next-IFD offset → IFD1 IFD1 — thumbnail metadata Compression: 6 (Old-style JPEG) JPEGInterchangeFormat: offset to thumbnail JPEG bytes JPEGInterchangeFormatLength: ~6 KB

EXIF doesn't just describe the photo. It carries a second photo inside the first — a small JPEG generated at capture time, typically 160×120, used by cameras and phones to render gallery previews without decoding the full image. It lives in a second TIFF IFD called IFD1, separate from the main metadata, with its own compression settings and pixel data. And it has an inconvenient property: most editors don't update it.

Where it lives

The EXIF block is structured exactly like a TIFF file. The main TIFF IFD (IFD0) ends with a 4-byte field giving the offset of the next IFD. If that offset is non-zero, a second IFD follows — IFD1 — describing the thumbnail. Two of its tags matter most: JPEGInterchangeFormat (offset to the thumbnail's compressed bytes) and JPEGInterchangeFormatLength (their total size). The thumbnail itself is a normal JPEG file — SOI marker, quantisation tables, scan data, EOI marker — embedded inside the parent JPEG.

Typical sizes: 160×120 pixels, 4–8 KB compressed. Some cameras write 320×240 or even 640×480 thumbnails for faster preview on the camera's rear display.

Why the thumbnail is often stale

When you crop or filter a photo in a desktop editor, the editor regenerates the main image — but updating the embedded thumbnail is an extra step that some editors skip, and many do skip. The result: a photo whose visible pixels are the cropped version, but whose EXIF thumbnail is the original uncropped frame.

The well-known illustration of this is the 2003 Cat Schwartz incident: a TV personality posted a tightly-cropped photo of her face. Someone extracted the EXIF thumbnail from the same file. The thumbnail was the original uncropped version, taken before the crop, with content the cropping had been intended to hide. The case made the rounds in early-2000s blog posts and is still cited in metadata-privacy talks.

Modern versions of the same leak

Cropping isn't the only operation that desyncs the thumbnail. Blur, redaction (drawing black rectangles over a face or licence plate), watermarking, and filter effects all produce a modified main image with an unmodified thumbnail. The leak surfaces if anyone with an EXIF-aware tool — or our viewer — extracts and displays the thumbnail beside the visible image.

Social platforms mostly side-step the issue by re-encoding uploads from scratch, which discards the embedded thumbnail along with the rest of the EXIF. But files emailed, shared via cloud-storage links, or sent over messaging apps that preserve the original (Telegram "Send as file", WhatsApp document mode) keep the thumbnail intact.

How our viewer shows it

The bundled ExifTool surfaces the embedded thumbnail's metadata — IFD1 fields like ThumbnailImage, ThumbnailOffset, ThumbnailLength, plus its own resolution and compression tags. The viewer shows these as individual tags in the standard table; the thumbnail's binary payload is reported as a length, not rendered visually. If you suspect the embedded thumbnail diverges from the visible image, you can extract it with a desktop tool (ExifTool's -b -ThumbnailImage) for inspection.

How to strip the thumbnail safely

Stripping IFD1 specifically is fiddly because it's nested inside the EXIF block; most desktop tools either strip all EXIF (which loses the camera info too) or strip nothing. Our remove-metadata button takes the all-or-nothing route: it runs exiftool -all=, which clears the thumbnail along with the rest of the EXIF (the ICC profile is preserved). For surgical per-tag stripping, use ExifTool from the command line.