Advice about photo location data is usually confident and untested. Crop it, resize it, convert it, screenshot it — somebody will tell you each of these is enough, and somebody else will tell you none of them are. So we built a photo with everything in it, pushed it through eight operations, and read the resulting files byte by byte.
The answer turns out not to be about which operation you choose. It is about whether the pixels get re-encoded at all — and the one case where nothing gets re-encoded is exactly the case where people assume they are safe.
What was in the photo
We wrote a JPEG carrying a full set of the fields a real camera or phone records. Not a stripped-down test file: the same tags your phone writes when location services are on.
| Field | Value in the test file | What it tells a stranger |
|---|---|---|
| GPSLatitude / GPSLongitude | 37°46′29.77″N, 122°24′51.08″W | Where you stood, to within a few metres |
| GPSAltitude | 15.24 m | Which floor, in a tall building |
| DateTimeOriginal | 2026:07:14 11:32:08 | Exactly when — to the second |
| Make / Model | Filewhisk FW-One | What you own |
| BodySerialNumber | SN-8841203977 | Links every photo you have ever posted to one camera |
| LensModel | FW 24mm f/1.8 | More of the same |
| Artist / Copyright | Your name | Your name |
| XMP packet | Creator, GPS repeated in XML | A second copy of the coordinates, in a different place |
That last row matters more than it looks. GPS coordinates often live in the file twice — once in the EXIF block, once again inside an XMP packet that some tools write and many metadata viewers never show you. A cleaner that only handles EXIF leaves the XMP copy sitting there.
The serial number deserves its own note. Coordinates tell someone where one photo was taken. A body serial number is a persistent identifier: it is the same in every photo that camera has ever produced, which makes an anonymous post and a photo on your public profile trivially linkable.
The measured results
Each operation ran in a real browser against the tools on this site, and each output was parsed back out field by field. “Gone” means the block is not in the file at all — not hidden, not blanked.
| Operation | Output | GPS | Camera | Serial | XMP |
|---|---|---|---|---|---|
| Crop | 3,554 B | Gone | Gone | Gone | Gone |
| Resize | 3,404 B | Gone | Gone | Gone | Gone |
| Rotate 90° | 3,637 B | Gone | Gone | Gone | Gone |
| Compress to 500 KB (file was already 8 KB) | 7,908 B — unchanged | Still there | Still there | Still there | Still there |
| Compress to 20 KB (file was 34 KB) | 15,634 B | Gone | Gone | Gone | Gone |
| Convert format | 3,404 B | Gone | Gone | Gone | Gone |
| JPG → WebP | 1,540 B | Gone | Gone | Gone | Gone |
| Remove EXIF data | 3,684 B | Gone | Gone | Gone | Gone |
The rule underneath the table
Seven rows look identical, and the reason they are identical is that all seven did the same thing: they decoded the photo into pixels and encoded a brand-new file from those pixels. A browser building a fresh JPEG writes the pixels and nothing else. There is no step that “strips” the metadata, because there is no step that copies it across. The old file's EXIF, GPS, serial number and XMP are simply not part of what gets written.
That is why cropping a single pixel off an edge removes the coordinates just as completely as a dedicated cleaner does. It is also why the outputs are so much smaller than the input: 3,404 bytes against 7,908, on a picture whose visible content barely changed. Over half the original file was metadata.
So the honest rule is: if the pixels were re-encoded, the metadata is gone. If they were not, all of it is still there.
The row that should worry you
Look at the fourth row again. The output is 7,908 bytes and so was the input — the same file, byte for byte. GPS, camera, serial number and XMP all survived, because nothing happened to the photo at all.
This is not a malfunction. A tool asked to bring a file under 500 KB, handed a file that is already 8 KB, has correctly decided there is no work to do. Re-encoding it would throw away image quality for no reason. Our own compress to 500 KB tool says so plainly — already under target — left untouched — and hands your original back.
The gap is between what that message says and what people hear. It is a statement about file size. It reads like a statement about the file. Somebody compressing a photo “to clean it up before posting” sees a success message, downloads a file, and shares a picture with their coordinates and their camera's serial number intact — and the one thing that would have removed them, actual re-encoding, is the thing the tool correctly skipped.
This is not specific to us. Any target-size compressor, anywhere, behaves this way, because it is the right behaviour. Which means “I compressed it” is never evidence that metadata is gone. The only evidence is looking.
What to actually do
- Check, don't assume. Open the file you are about to send in view image metadata and look at it. This takes five seconds and is the only step that produces certainty.
- Use a tool whose job is removal. Remove EXIF data re-encodes unconditionally, so there is no “nothing to do” path that quietly returns your original.
- Turn it off at the source. iPhone: Settings → Privacy & Security → Location Services → Camera → Never. Android: Camera app settings → turn off location tags. Nothing recorded is nothing to remove, and it is the only approach that protects the photos you forget to check.
- Don't rely on the platform. Large social networks generally re-encode uploads, which removes metadata as a side effect — but that is a side effect of their compression, not a promise to you. It does not apply to a photo sent as an email attachment, posted to a forum, uploaded to a classified ad, or sent as a “document” rather than a photo in a messaging app, which is precisely the option people pick when they want to preserve quality.
A note on screenshots
Screenshotting a photo to strip its metadata does work — a screenshot is new pixels in a new file, with none of the original's blocks. It is also the worst available option for quality: you get a lossy copy at screen resolution, cropped to whatever the viewer showed. Every tool in the table above achieves the same removal without destroying the picture. Use one of them instead. If what you were really after was a smaller file rather than a cleaner one, the image compression tools do that properly — and, as the table shows, remove the metadata on the way whenever they actually re-encode.
How this was measured
The test file was built by writing EXIF and XMP blocks directly into a JPEG, so we knew exactly which fields went in. Each operation then ran against the live tools in a real headless Chrome, driven through the DevTools protocol, and each downloaded output was parsed back with a reader written for the purpose — walking the JPEG segment list, the PNG chunk list and the WebP RIFF chunks, so that a surviving block could not hide in a container we were not checking. The figures in the table are the byte counts those files actually had.