Why a cropped photo still shows what you cropped out

Because the photo is carrying two pictures, and you only edited one of them. When the shutter fires, the camera writes a small complete JPEG — usually 160 by 120 pixels — into the file's EXIF block, so a picture browser can show you a preview without decoding the full image. If you later crop the visible photo, the format does not require the editor to replace that small one. Some do. Some do not. When it does not, the file you send still contains the frame you cropped away, at a size that is perfectly good enough to read a face, a screen, a door number or a document. CLOAK shows you the one inside your own photo, in the page, without uploading it.

Where it actually is

The EXIF block sits in a JPEG segment marked APP1, near the front of the file, and inside it is a small TIFF structure. That structure has directories: IFD0 describes the photo — camera make and model, the time, the lens, often GPS — and at the end of IFD0 is a four-byte pointer to the next one. That next directory is IFD1, and IFD1 describes the thumbnail.

It does it with three tags:

Read those, and the bytes between them are a whole JPEG of their own, starting with the same FF D8 that starts any JPEG. You can save it out and open it. That is why this is not a preview in the sense of a cache or a hint: it is a second photograph, travelling inside the first one.

It is small because it has to be. A JPEG segment carries a two-byte length field, so the entire APP1 block — EXIF, GPS, maker notes and thumbnail together — cannot exceed 65,535 bytes. That ceiling is the only thing keeping the thumbnail down to a few kilobytes, and a few kilobytes at 160 by 120 is a clear picture of a face.

Why an editor leaves a stale one behind

Because nothing tells it not to. Regenerating the thumbnail is a separate piece of work from writing the new pixels: the editor has to re-scale the edited image, encode a second JPEG, and rebuild IFD1 around it with corrected offsets. Copying the original EXIF block across unchanged is one operation and preserves the camera information people expect to keep. The specification does not make the first mandatory, so whether your editor does it is a property of your editor and not of the format.

This is why the advice you will find — "most editors update it", or "most editors don't" — is not worth much either way. The only statement that holds for your photo is the one you get by looking at your photo.

The failure is old and it is well documented. In 2003 a television presenter posted a cropped headshot to a blog; the EXIF thumbnail inside it was the uncropped original, somebody pulled it out, and it became the case everybody cites. Twenty-three years later the mechanism has not changed, because there is nothing about it to fix: the format is behaving exactly as specified.

How to tell, and what the test cannot tell you

Open the photo in CLOAK. If there is a thumbnail it is displayed, at its own size in pixels, next to the photo you can see. Then compare the two by eye, because you know what was supposed to be in the picture and no piece of software does.

The page does give you one mechanical hint. If the thumbnail's proportions are different from the photo's — 1.33:1 against 1:1, say — then the picture was reshaped after the thumbnail was made, and the thumbnail is showing you a frame that no longer exists. That is a reliable positive. It is not a reliable negative, and the page says so rather than reassuring you:

• A crop that keeps the same proportions — trimming a border evenly, zooming in on the centre — leaves the ratio identical and the thumbnail just as stale.
• A redaction painted onto the image, a black box or a blur, does not change the shape at all. The thumbnail keeps the unredacted version.
• Some editors rewrite the thumbnail correctly, in which case the shapes match because everything is fine.

Those three cases are indistinguishable by arithmetic and obvious by eye, which is why the tool shows you the picture instead of giving you a verdict.

What removes it, and what only looks as though it does

Re-encoding is the one that is certain, and it is certain for a dull structural reason rather than a clever one: the new file is written from the pixel data, so every block that was wrapped around the old pixels — thumbnail, GPS, camera serial number, maker notes, XMP — simply has no path into it.

The same shape of problem, elsewhere

A file holding an older version of itself is not a photography problem, it is a file-format problem, and it turns up wherever a format was designed to be appended to rather than rewritten.

• A PDF can be saved by writing changes on the end and leaving the original objects in place, which is how text under a redaction box stays readable.
• A Word document keeps more of its own history than most people expect, including content that was deleted and identifiers tying edits to sessions.
• And in a photo, the metadata beside the thumbnail is often the more serious half: where it was taken, to about five decimal places.

What this is and is not

CLOAK reads the EXIF structure in your browser and shows you what is in it, including the thumbnail as an image rather than as a line of text saying one exists. Exporting a cleaned copy re-encodes the pixels, which removes the lot.

It is not a guarantee about what a service does to your file after you upload it, it cannot show an uncompressed thumbnail of the rare kind, and it does not know what was supposed to be in your picture. The comparison it offers is a prompt to look, not a finding.