Stripping Photo Metadata: What Actually Comes Off

A photo file is not one metadata block, it is six

Almost everyone says EXIF when they mean metadata, and that is where the trouble starts. EXIF is one block among several, and a JPEG is a sequence of labelled segments that can each hold something different. There is the JFIF segment with basic density information. There is the EXIF block itself, which holds the camera make and model, the editing software, the timestamp, the exposure settings, sometimes the body serial number and the lens, and — as a separate sub-directory — the GPS position. There is XMP, an XML packet that editing software uses for its own fields. There is an IPTC record, usually wrapped in a Photoshop resource block, carrying captions, bylines and rights. There is an ICC colour profile. And there is a plain comment segment that anything can write into.

The one worth knowing about is hidden inside EXIF rather than beside it: a second, complete copy of the picture, at thumbnail size, stored so that a camera can show you a preview instantly. In the test file we built, that thumbnail was 5,628 bytes of real JPEG. It matters because a tool that edits the main image and rewrites only the tags it recognises can leave the thumbnail untouched — and then the small version still shows the scene as it was before you cropped, straightened or covered something up. Other formats have their own arrangements: a PNG stores text in tEXt, zTXt and iTXt chunks and can carry a whole EXIF block in an eXIf chunk, while HEIC and WebP wrap their own containers around the same kinds of records.

As for what the location field is worth: coordinates are stored as three rational numbers — degrees, minutes and seconds — and the seconds field carries fractions. A file written with hundredths of a second resolves to roughly a foot on the ground. That is not the neighbourhood, it is the room. Combine it with the exact timestamp, which is stored to the second, and a photo of a child at home is a home address and a routine.

Two ways to remove it, and they are not equivalent

The first way is surgical: open the container, walk the list of segments, delete the ones you do not want, and write the compressed image data back out untouched. Nothing is decoded, nothing is re-encoded, and the pixels that come out are bit-for-bit the pixels that went in. This is how a metadata editor works, and it is the right approach when quality matters. Its weakness is that it only removes what it knows to look for — an unfamiliar segment, a maker-specific block, a nested record it does not parse, all survive by default.

The second way is blunt and is what this tool does: decode the picture to raw pixels, draw those pixels onto a canvas, and ask the browser to serialise the canvas as a new file. The browser standard describes this output as a serialisation of the canvas bitmap, and a bitmap is nothing but colour values — there is nowhere for a camera serial number or a hidden thumbnail to be stored, because the structure that held them was thrown away several steps earlier. That is why this approach cannot miss anything: it is not a list of things to delete, it is a refusal to copy anything except the picture.

What actually came off

We built a file that carried all of it and put it through. The source was an 800 by 600 JPEG of about 60 kilobytes, holding a JFIF segment, a full EXIF block with make, model, editing software, timestamp, exposure time, aperture, sensitivity, the camera body serial number, the lens model and a GPS position with altitude, a 5,628-byte thumbnail inside that EXIF block, an XMP packet naming a photographer and a city, an IPTC record with a caption and a byline, a colour profile, and a comment reading that the file was an internal draft not to be distributed.

The cleaned output was about 58 kilobytes and contained four things: the JFIF segment, a colour profile, the compression tables, and the image data. Nothing else. We then searched the exported bytes directly for fourteen strings taken from the original — the camera maker, the model, the editing software, the serial number, the lens name, the photographer's name, the caption, the do-not-distribute comment, the XMP markers, the word Exif itself, the timestamp and the numeric form of the coordinates. Not one of them appears. The hidden thumbnail is gone too: the only byte sequence the two files share is the standard header that every image encoded by that browser carries, and it stops well before the thumbnail's own picture data begins.

One thing is preserved on purpose, and it is the right one. Cameras and phones very often store the picture in its sensor orientation and add a tag saying how to turn it. If you deleted the tag and kept the pixels, every portrait photo would come out on its side. We tested a version of the file marked as needing a quarter turn: the browser applied the rotation before the canvas ever saw it, so the cleaned file measured 600 by 800 instead of 800 by 600 and stands upright with no tag left to interpret. That is exactly the behaviour you want and it is worth confirming, because tools that strip tags without decoding get this wrong all the time.

What the re-encode costs

Thoroughness is bought with quality. Because the picture is decoded and compressed again, the output is not the original image — it is a new lossy approximation of it. On our test file one pass measured 46.2 decibels of signal-to-noise ratio against the source, with a worst-case single-channel error of 18 out of 255. In plain terms that is invisible on a screen and would survive a print. It is not nothing, though, and it is not free: a surgical metadata removal would score infinity, because it changes no pixels at all.

The part to watch is repetition. The loss compounds, because each pass starts from the previous pass's approximation rather than from the original. We ran the cleaned file back through five more times: the signal-to-noise ratio against the original fell from 46.2 to 38.5 decibels, and the worst single-channel error grew from 18 to 53 out of 255. That is the difference between invisible and visible in a flat sky or a skin tone. So clean once, at the end of your editing, on the file you are about to send — not habitually, and not on a file you will edit again afterwards.

Where it breaks: iPhone photos, transparency and colour

The important gap is HEIC. It is the default capture format on an iPhone, and desktop browsers generally cannot decode it. We fed a real HEIC file in and the image decoder failed outright — and because the tool has no handler for that failure, nothing at all happens: no cleaned image, no download button, no message. A user who does not know the format is unsupported will reasonably conclude the page is broken, or worse, will not notice and will assume the job was done. Convert to JPEG first, or export from the phone as JPEG rather than sharing the original capture.

The second surprise is that the output is always a JPEG, whatever went in. Feed it a PNG and you get a JPEG back, with the extension changed for you. That is fine for a photograph and wrong for anything with transparency: JPEG has no alpha channel, so partly transparent pixels are flattened against a background. We measured it on a PNG whose right half was about half transparent, and the exported pixels came back fully opaque and much darker, having been composited onto black. A logo, a screenshot with rounded corners or a cut-out product image will not survive this intact. Colour is treated the same way: the canvas works in the standard sRGB space and the exported file carries the browser's own sRGB profile, written even when the input had no profile at all — so a wide-gamut photo comes out converted rather than preserved.

Where it leaks, and when a screenshot is the right answer

The leak is almost never the social network. Large platforms re-encode what you upload, mostly to save bandwidth, and metadata disappears as a side effect — but that is a consequence of their pipeline, not a promise to you, and it varies by platform and by upload path. The reliable leaks are the routes where nobody re-encodes anything: a file attached to an email, a photo dropped into a chat as a document rather than as an image, an upload to a forum or a classifieds site that stores what it is given, a file handed over on a memory stick, a picture posted to a small site running off-the-shelf software. In every one of those the bytes you send are the bytes that arrive, thumbnail and coordinates included.

And yes, a screenshot really does work — for one photo. Photographing the screen with a screenshot key produces a fresh file made of nothing but the pixels you can see, with none of the original blocks attached, and it takes two seconds. It also throws away resolution, since you capture the picture at the size it was displayed rather than at its native size, and it does not scale: two hundred holiday photos are two hundred manual operations and a folder full of screen-sized copies. That is the honest boundary between the two answers. One image, and the fastest correct thing is a screenshot. More than a handful, and you want a tool that does the same job to the whole batch without you watching.

Frequently asked questions

Does it definitely remove the GPS position?

Yes. GPS coordinates live in a sub-directory of the EXIF block, and the EXIF block is not edited — it is discarded along with the whole original container when the pixels are re-encoded. In our test the source held a latitude, a longitude and an altitude; searching the cleaned file for the numeric form of those values returns nothing, as does searching for the word Exif itself. Nothing about location can survive a process that only copies colour values.

Does the hidden thumbnail survive?

No — and it is worth checking, because this is where other tools fail. A cleaner that edits tags in place can leave the thumbnail untouched, and the thumbnail may show the scene before you cropped or covered something. Here the thumbnail cannot survive: it lives inside the EXIF block, and the EXIF block is never copied. We confirmed it by comparing the two files byte by byte — the longest run they share is the standard header every image from that browser carries, and it ends before the thumbnail's own picture data would begin.

Does cleaning lose image quality?

A little, and only once if you use it once. The tool decodes the photo and compresses it again, so the output is a new lossy version. Measured against our source, a single pass came out at 46.2 decibels of signal-to-noise with a worst single-channel error of 18 out of 255 — invisible in normal viewing. Repeated passes compound: after six the ratio had fallen to 38.5 decibels and the worst error had grown to 53. So clean once, on the copy you are about to send, and keep your untouched original elsewhere.

I loaded a photo from my iPhone and nothing happened. Why?

Almost certainly because the file is a HEIC, which is what an iPhone captures by default and which desktop browsers generally cannot decode. We reproduced it with a real HEIC file: the decoder fails, and the tool has no handler for that failure, so the page simply does nothing — no image, no download, no error. Convert the file to JPEG first, or change the camera setting so the phone captures in the most compatible format, or share the photo through an app that converts on export.

How can I check for myself that a file is clean?

Do not rely on your operating system's file information panel — it shows a curated selection of fields, not everything present, and a block it does not understand simply will not appear. Two better checks: open the file in a metadata viewer that lists raw segments rather than friendly labels, or compare file sizes, since a photo that shrinks noticeably after cleaning was carrying a hidden thumbnail. And confirm what you actually sent rather than what you cleaned — the file that leaves your machine is the one that matters, and messaging apps sometimes re-attach or re-encode along the way.