The hidden thumbnail problem

There's a small image hidden inside most JPEG files. It's a low-resolution preview — typically 160×120 pixels — embedded in the EXIF block so that file browsers, cameras, and photo apps can display a quick preview without decoding the full-size image.

This preview thumbnail is a separate, independent image. And here's the problem: it has its own metadata.

What the thumbnail is and why it exists

When your camera writes a JPEG, it encodes the full-resolution image and then — inside the EXIF segment — it also writes a small compressed preview. This lets your camera's playback screen, your operating system's thumbnail generator, and apps like Lightroom show you a fast preview without reading the entire file.

In the EXIF standard, the thumbnail is stored as a baseline JPEG in the IFD1 (Image File Directory 1) block, after the primary IFD0 block that carries the main metadata tags.

The thumbnail and the main image are treated as independent images inside the file. The thumbnail has its own image dimensions, its own color profile, and its own set of EXIF tags — including, potentially, GPSLatitude and GPSLongitude.

Why this is a privacy problem

Imagine a naive metadata-stripping approach: find the EXIF APP1 segment in the JPEG, remove the GPS tags from IFD0 (the main image metadata), and write the file back.

If that implementation doesn't also clear the GPS tags from IFD1 — the thumbnail's metadata — the location is still in the file. A tool like exiftool will report it. The thumbnail's GPS block survived the cleanup.

This isn't a theoretical concern. It's a real behavior that affected early versions of metadata tools, and it still shows up in "light touch" approaches that clear only the most obvious GPS fields rather than stripping the entire EXIF segment.

There's a second issue: the thumbnail might not match the main image at all. If you cropped a photo in editing software, the thumbnail might still show the original uncropped version — including anything that was in the frame before the crop. Some forensic techniques exploit this to recover what was removed from a "cropped" image.

What's actually in the thumbnail metadata

The thumbnail's EXIF section (IFD1) typically carries:

• Compression — the format of the thumbnail (usually 6, meaning JPEG)
• XResolution and YResolution — thumbnail DPI
• JPEGInterchangeFormat — byte offset to the start of the thumbnail data
• JPEGInterchangeFormatLength — size of the thumbnail in bytes

Those are the standard tags. But in practice, camera manufacturers write additional tags into IFD1, and some of them include GPS coordinates copied from the main image. It's redundant from a spec perspective, but it happens.

You can verify this on any photo from a DSLR or recent smartphone:

exiftool -G1 -gps:all your-photo.jpg

The -G1 flag shows the group (IFD0 vs IFD1 vs ExifIFD, etc.), so you can see if GPS coordinates appear in both the main and thumbnail sections.

How CleanImages handles this

The correct approach — and the one that matters — is to not "clear GPS tags" at all, but to surgically reconstruct the EXIF block without any of the metadata you're removing, including the thumbnail and its associated IFD1 section entirely.

CleanImages strips the THMB (hidden thumbnail) layer as one of seven distinct removal operations. This isn't deleting a tag; it's removing the entire embedded preview image along with its metadata from the reconstructed byte stream. The result is a file where the IFD1 block doesn't exist at all — there's nothing left to carry GPS coordinates.

The reason this matters is that partial approaches create a false sense of security. A file that reports zero GPS in the primary EXIF can still have GPS in the thumbnail. Anyone running exiftool -a -u -g1 (all tags, unknown tags, grouped by IFD) on the "cleaned" file will find it immediately.

How to check your own files

If you want to audit a file before or after cleaning:

Using exiftool:

exiftool -a -u -g1 your-photo.jpg | grep -i gps

The -a flag shows duplicate tags, -u shows unknown tags, and -g1 groups by IFD level. If GPS shows up under IFD1 after cleaning, the thumbnail wasn't stripped.

Using a hex editor: The thumbnail JPEG starts with FF D8 FF inside the EXIF block. The GPS data would appear in the TIFF header that precedes the thumbnail's IFD section — you'd see the latitude and longitude encoded as TIFF rationals.

Using CleanImages: Drop in a file and look at the metadata report. We flag the hidden thumbnail as a distinct item so you can see it was there before stripping. The clean file won't have it.

The broader lesson

Metadata removal is only as good as its coverage. A tool that removes EXIF but leaves IPTC, XMP, and the thumbnail has done the obvious work without finishing the job. Privacy claims about metadata cleaning should be specific about what's actually removed — not just "we strip EXIF" but whether that means rewriting the full byte stream or just nulling out a few fields.

The thumbnail is a good test case. It's obscure enough that many tools miss it, but it's easy enough to verify that you can check for yourself in 30 seconds.