YOUR PHOTO HAS A VIDEO INSIDE IT
Take a photo on a Pixel or a recent Galaxy with motion on, and you get one file. It looks like a JPEG, it is named like a JPEG, and every app treats it like a JPEG. Inside, after the picture ends, sits an entire MP4 of the second or two around the shot.
That clip is a file in its own right. It has its own metadata: its own GPS coordinates, its own camera model, its own creation time, sometimes its own software string. And because it lives past the end of the image, most metadata tools never look at it.
Why tools miss it
A JPEG has a defined end. There is a two-byte end-of-image marker, and by the letter of the format, that is the end of the file. A cleaner walks the segments at the front, drops the ones holding EXIF and XMP, copies the compressed image data, and stops thinking. Whatever bytes follow the end marker get copied along verbatim, because as far as the tool is concerned they are just the rest of the file.
So you get the worst possible outcome: a badge that says clean, a photo whose EXIF really is gone, and a hidden video inside it that still knows exactly where you were standing.
MetaStrip had this bug too. It was found while building video support, and fixing it is the reason this post exists.
Finding the real end of a picture
You cannot just search the file for the end marker, because compressed image data is full of byte patterns that look like markers. The format saves you here. Inside entropy-coded data, every 0xFF byte is stuffed as FF 00, and the only markers allowed to appear are the restart markers FFD0 through FFD7. An FFD9 cannot occur inside the scan. So the first FFD9 after the image data starts is the true end of the picture, exactly, with no guessing. Everything after it is an addition.
What MetaStrip does with it now
The tail gets handed to the video parser, so instead of a vague warning you see what is really in there: the clip's duration, its frame size, its camera model, its coordinates. If the photo's own EXIF is clean but the buried clip still has GPS, the location alert fires anyway, because the leak is just as real.
Then one tick box removes the whole tail. That is a genuine cut rather than a blanking, because nothing in the JPEG references those bytes, so your file gets smaller by however many megabytes the clip was.
Two related things people get wrong
Apple Live Photos are different. On an iPhone, the photo and the video are two separate files that a pairing identifier ties together. MetaStrip reads that identifier and reports it, because it is the thing that proves two files came from one capture. AirDrop a Live Photo and both halves travel.
Samsung appends other things too. Galaxy phones write a block of extra data closed off with a SEF footer, which is not a video but is still a chunk of vendor metadata living past the end of your picture. It gets found and reported separately, rather than being mislabelled a hidden clip.
If you have a motion photo on your phone, drop it in and look at the row that says Hidden video. It is a strange feeling the first time.