Measured 17 September 2026
What your photos reveal, and what removing it actually costs
A phone photograph carries a block of hidden data: where it was taken, to about a tenth of a metre, when, on which device, and often the serial number of that exact camera body. I built test photographs carrying known metadata, read them with this site’s own parser, and measured what each way of removing it does to the picture. The short version: stripping the metadata left a file byte-for-byte identical to one that never had any, and converting the photo instead is the expensive way round.
What was actually in the file
The test photograph carries 346 bytes of EXIF — about half a percent of a 68 KB file, and invisible unless you go looking. Here is what the metadata reader on this sitepulled out of it, verbatim:
| Field | Value | Why it matters |
|---|---|---|
| GPS position | 27.703428, 85.328669 | Six decimal places is roughly a tenth of a metre. This is not "the city you were in" — it is the doorway. |
| Date and time taken | 2026:06:14 09:31:07 | To the second, in the camera’s local time. Combined with the position it places you somewhere at a moment. |
| Camera make | Acme | Identifies the manufacturer of the device that took the photo. |
| Camera model | Acme Phone 14 Pro | Narrows the device to a specific model, and so a price bracket. |
| Lens | Acme 26mm f/1.8 | Which camera on a multi-camera phone, which is a detail about the device. |
| Body serial number | SN-TEST-0001 | The strongest field here: it links every photo from one physical device to every other. |
| Software | AcmeOS 19.2 | The operating system version, which is a fingerprinting detail. |
The coordinate is the one worth sitting with. Six decimal places of latitude and longitude is a precision of roughly ten centimetres. A photo of a cat on a sofa, posted publicly, can carry the position of the sofa. And because the body serial number travels with every photo from the same device, a set of images from different accounts can be tied to one physical camera without any other evidence.
Not every photo carries all of it. The second test file had the camera fields and the timestamp but no GPS — 154 bytes instead of 346 — which is what you get when location services were off for the camera. The only way to know which case you are in is to look.
Three ways to get rid of it, measured
All three work. They cost very different things, and the difference is not obvious from the outside.
| Method | Result | Pixels unchanged | Image data unchanged |
|---|---|---|---|
| Strip the metadata | 68 KB | Yes | Yes |
| Re-save as JPEG (quality 88) | 62 KB | No | No |
| Convert to PNG | 674 KB | Yes | No |
- Strip the metadata. The EXIF segment is removed and the compressed image data is left alone. The result was byte-for-byte identical to the control photo — same SHA-256 — so this is not "almost lossless", it is the same file the camera would have written if it had never recorded anything.
- Re-save as JPEG (quality 88). Decoding and re-encoding drops the metadata as a side effect. At a quality that matches the original the pixel cost was negligible, but the file is a new encode rather than the original, and nothing about that is reversible.
- Convert to PNG. Pixel-for-pixel identical to the decoded JPEG, and just under ten times the size. It removes the metadata, but it is the most expensive way to do it and it cannot recover any detail the JPEG already discarded.
Stripping is not "nearly" lossless
This is the result I most wanted to check, because it is the claim the tool makes. Removing the EXIF segment and leaving the compressed scan data alone produced a file whose SHA-256 matched the control photograph exactly — the same picture saved without metadata in the first place. Not close to it. The same 68 KB, the same hash.
That is worth stating precisely because “lossless” gets used loosely. A JPEG’s image data lives in segments that have nothing to do with the EXIF segment, so removing one does not require touching the other. No decoding happens, no re-encoding happens, and there is no quality setting to get wrong.
The re-encode folklore is half right
The common advice for removing metadata is to convert the photo, or screenshot it, or re-save it. That does work — every re-encode in this test came out with no metadata at all. But it is worth knowing what you are paying, and the answer is less alarming than the usual warnings suggest, in one direction and worse in another.
| Re-encode quality | Size | Mean drift | Worst | Channels changed |
|---|---|---|---|---|
| 0.95 | 81 KB | 0.081 | 3 | 7.4% |
| 0.88 (matches source) | 62 KB | 0 | 1 | 0% |
| 0.75 | 34 KB | 0.992 | 9 | 67.9% |
| 0.6 | 21 KB | 1.229 | 9 | 74.4% |
| 0.4 | 13 KB | 1.521 | 11 | 79.4% |
Re-encoding at the quality the file already had moved the pixels by nothing measurable — mean drift 0, with 0% of colour channels changed at all. A single re-save at a matching quality is very nearly a no-op, because the coefficients are already quantised to that grid. The widely repeated idea that any re-save visibly wrecks a JPEG is overstated for one pass.
Two things do cost you. Asking for more quality than the file contains is pure waste: at 0.95 the file grew to 81 KB — about 20% larger than the original — while moving 7.4% of channels and recovering nothing, because the detail was already gone. And dropping below the source quality is a real loss: at 0.6, 74.4% of channels changed. None of it is reversible, and it compounds every time the picture is saved again.
Converting to PNG is the other end of the trade. It kept the decoded pixels exactly, removed the metadata, and produced 674 KB — almost ten times the original. It works, and it is the most expensive way to do it.
What I would actually do
If the goal is to remove the metadata and nothing else, strip it. It is the only one of these that leaves the photograph untouched, and you can confirm that yourself by comparing checksums rather than taking my word for it.
Re-encoding is a reasonable choice when you were going to re-encode anyway — you are already resizing or compressing the picture for somewhere, and the metadata going with it is a free side effect. Doing it only to remove metadata means paying for a decode and encode you did not need.
And it is worth checking before you assume. Most social platforms already strip EXIF on upload; plenty of messaging apps, cloud drives, and direct file transfers do not. The metadata tool here shows you what is in a file before it removes anything, which is the part that matters — a tool that silently removes something you never saw cannot tell you whether you needed to worry.
Limits of this test
- Built photographs, not camera files. The test images are generated so that anyone can rebuild identical ones. A real camera writes more tags than these — including maker-note blocks that are proprietary and often large — so a real photo generally carries more metadata than 346 bytes, not less.
- EXIF only. These files carry EXIF. They do not carry XMP or IPTC blocks, which editing software adds and which can hold author, copyright, captions and editing history. The parser reports those blocks when present; this test did not exercise that path.
- Drift depends on the picture. The re-encode figures come from one generated photograph. An image with harder edges or finer texture will drift more at the same quality. The shape of the result — matched quality cheap, higher quality wasteful, lower quality lossy — is the part that generalises, not the exact numbers.
- One encoder. Chromium’s, reached through the same
canvas.toBlobcall the tools here use. Other encoders land elsewhere at the same nominal quality. - Nothing here is a privacy guarantee. Removing EXIF removes EXIF. It does not address what is visible in the picture, which is frequently more identifying than the coordinates attached to it.
Repeat it yourself
Both scripts are in this site’s repository. The first builds the test photographs with Pillow, the second reads and strips them with the site’s own code and runs the re-encodes in Chromium — two independent implementations on either side of the file, which is the only reason the read-back means anything.
python3 scripts/make-metadata-test-photos.py tmp/photos
npx tsx scripts/measure-metadata-survival.mjs tmp/photosTo check your own photo rather than mine, open Remove EXIF Data and drop it in. It lists what it found before it changes anything, and like everything here it runs in your browser — the photo you are checking for hidden location data is not uploaded to check it, which would rather defeat the point. The PDF tool study in this section covers how to verify that claim for yourself.