What is actually inside a photo
Open any photo straight off a phone and the picture is only part of the file. Wrapped around it is a block of metadata the camera wrote at the same moment: the device make and model, the lens, the exposure settings, the exact second the shutter fired, the operating system version, and — when location services are on — the latitude and longitude of where you were standing, usually accurate to a few metres.
None of that is visible in the image. All of it travels with the file. Send the photo as an email attachment, drop it in a shared folder, list an item for sale with it, and every one of those fields goes with it.
The tool above reads that block out and shows it to you before it removes anything, because the numbers are the argument. "This photo contains EXIF metadata" is abstract. A pair of coordinates that resolve to your front door is not.
Strip the bytes, do not re-encode
There are two ways to remove metadata from an image, and only one of them is right.
The easy way is to draw the picture onto an HTML canvas and save it again. The metadata disappears because a canvas never carried any. It also re-compresses the picture — a second round of lossy JPEG compression on top of the camera's — and drops the embedded colour profile, so the "cleaned" file is measurably worse than the original and its colours have shifted. Most free metadata removers work this way, and it is why the file you get back is often a different size and a slightly different picture.
This tool does the other thing. A JPEG is a sequence of marker segments; a PNG is a sequence of chunks;
a WebP is a RIFF container. Metadata lives in specific, identifiable segments in each — APPn blocks in
JPEG, eXIf, tEXt, iTXt, zTXt and tIME chunks in PNG, EXIF and XMP chunks in WebP. Removing
them is a matter of walking the file's own structure, skipping those blocks, and copying everything else
across unchanged.
The compressed picture is never decoded. That means the image data in the file you download is bit-for-bit the image data in the file you supplied — not "visually identical", not "high quality", identical. The only difference between the two files is the metadata that came out.
What we do not remove, and why
Two things are deliberately kept, and both are shown to you with a checkbox in case you disagree.
The colour profile. An ICC profile describes which colour space the pixels are encoded in. Modern phones shoot in a wide gamut, and a wide-gamut photo without its profile is interpreted as ordinary sRGB and renders wrong — usually washed out, sometimes lurid. The profile describes the image, not the photographer, so it stays by default.
The rotation flag, when the photo needs it. Phones do not rotate the pixels when you turn the camera; they store the photo as the sensor saw it and write a single EXIF number saying which way up it belongs. Remove that number and the clean copy comes out sideways in any app that respects it. When a photo relies on it, this tool rebuilds a minimal block containing that one value and nothing else — no camera, no timestamp, no location.
Where this leaves your other photos
Cleaning a file before you send it solves the sharing half of the problem. It does nothing for the photos still sitting in your camera roll, which keep every field this tool just removed and are readable by anything with access to the device.
That is the half Vaultine exists for: an encrypted vault where files are locked with AES-256-GCM on the device itself, opened in a built-in viewer rather than decrypted out to disk, and unlocked with a pattern or PIN rather than an account. It is a different job from this page — Vaultine stores files, it does not edit their metadata — but the two halves of the same instinct. Photos you share leak where you were. Photos you keep should be locked.
