A JPEG can contain GPS coordinates, capture times, camera and lens details,
editing software, comments, and copyright fields. That may be useful in a
private archive, but risky in a public issue, marketplace listing, or social
post.
Do not assume the upload destination will remove it. Platforms process formats
differently and can change behavior. Create a clean public copy before the file
leaves your control.
Inspect a sharing copy
Keep the original private. On a separate copy, check for GPS data, timestamps,
camera identifiers, and EXIF, XMP, or IPTC fields. The goal is not to damage
your archive; it is to make a public file containing only what the destination
needs.
A practical workflow is:
- Inspect the sharing copy locally.
- Export a cleaned file.
- Inspect that exact output again.
- Review what is visible in the pixels.
- Rename it clearly before uploading.
The MonoTools EXIF Inspector & Cleaner does this in the current browser tab.
The selected photo is read through browser APIs and is not uploaded to a
processing server.
Understand the JPEG boundary
JPEG stores metadata in segments around its compressed image data. The cleaner
can remove those segments without recompressing the pixels. It currently
removes APP1 EXIF and XMP, APP2 ICC profiles, APP13 Photoshop and IPTC data,
and JPEG comments when present.
Removing an ICC profile can change color rendering in managed workflows, so
compare the cleaned copy with the original when color accuracy matters.
The cleaned export currently supports JPEG only. PNG and WebP use different
container structures; the tool can inspect them but does not yet rewrite their
metadata.
Check the pixels too
Metadata removal cannot hide information already visible in a photo. Look for
street signs, faces, badges, vehicle plates, screens, shipping labels, QR
codes, landmarks, and reflections. Cropping, blurring, or replacing the image
may still be necessary.
If the public copy also needs resizing or format conversion, do that after the
privacy review, then inspect the final file again. Compression and metadata
cleanup solve different problems.
I maintain MonoTools and wrote a fuller guide for its browser-local EXIF
Inspector & Cleaner:
Disclosure: MonoTools is my project.
Top comments (9)
Great reminder. One thing I’d add is that metadata removal should be treated as just one layer of privacy protection. Even a perfectly cleaned image can still reveal sensitive information through what’s visible in the pixels—reflections, unique landmarks, badges, screens, or shipping labels are often enough for OSINT investigations. Metadata is easy to strip; contextual information is usually the harder privacy leak to eliminate.
Exactly. I treat metadata cleanup as one checkpoint, not the finish line. The pixel review is the step people skip most often, especially reflections, screens, labels, and location clues. Thanks for calling out the OSINT angle.
Absolutely. I also encourage people to verify the final uploaded version, not just the local copy. Some platforms recompress, resize, or convert images, and while that’s usually about quality rather than privacy, it’s worth checking exactly what ends up being publicly accessible. Trust, but verify. 🙂
Agreed. The artifact that matters is the version served publicly, not only the local export. A final check should download that published file and inspect its metadata, dimensions, color profile, and visible pixels again. Platform processing can change the file even when it does not create a privacy issue.
One more thing I’d add is that privacy reviews should become part of the publishing workflow, not a last-minute manual check. The more repeatable the process is (clean → inspect → publish → verify), the less likely someone is to accidentally expose sensitive information under time pressure. Security usually improves when good habits become routine rather than something we have to remember each time.
That framing is the part I want to keep. A useful privacy workflow should be repeatable: clean locally, review visible pixels, publish, then download the public file and compare what the platform actually served.
I am going to treat that as a workflow boundary, not just an EXIF feature. The tool can make the checks explicit, but the final judgement still has to happen before each publish.
I like the idea of defining it as a workflow boundary rather than a feature. The next logical step is automation. If a publishing pipeline can automatically fail when GPS metadata is present or flag images that still contain obvious sensitive content, privacy becomes part of quality assurance instead of relying entirely on human memory. The fewer manual decisions required before publishing, the fewer privacy mistakes slip through.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.