Nothing leaves the machine
The file is read from disk by the page, parsed byte by byte for its metadata segments, decoded by the browser, redrawn into a canvas and re-encoded. Every one of those steps happens inside the tab. No request goes out when you pick a file, and the tool works with the network disconnected — which is the only way to check a privacy claim without taking somebody's word for it. That matters more here than on most pages, because the files people bring to a metadata stripper are precisely the ones they do not want on a stranger's server.
What is actually in there
Four separate things travel inside a typical JPEG and they are not the same thing:
| Block | Typically holds | Why it matters |
|---|---|---|
| EXIF | Capture time, camera make and model, lens, exposure, orientation flag, GPS coordinates, sometimes a body serial number and an owner name | The privacy block. GPS and serial number are the two that identify a person or a place |
| XMP | Editing history, ratings, keywords, captions, software identifiers | Leaks workflow detail and sometimes names in a credit field |
| IPTC | Caption, byline, copyright, location names written by a person | Deliberate, so removing it can be the wrong move for licensed work |
| ICC profile | How the numbers in the file map to real colours | Not private at all, but dropping it changes how the picture looks |
A serial number is the one people underestimate. It is stable across every photograph a camera body produces, so a set of images posted in different places under different names can be tied together by a field nobody looks at.
The rotation trap
Phones do not rotate the sensor data. They write the picture in whatever orientation the sensor read it and set an EXIF orientation flag saying how to turn it for display. Strip the metadata without thinking and the flag goes with it, and a portrait photo that looked upright in every viewer you own comes out lying on its side.
The fix is to bake the rotation into the pixels before encoding, and the awkward part is knowing whether it has already been baked in. Since around 2020 browsers apply the orientation flag themselves while decoding an image, so by the time the picture reaches a canvas it is usually already upright — and applying the flag a second time rotates it twice. This tool works out which case it is in by comparing the dimensions stored in the JPEG frame header against the dimensions the browser reports after decoding. If they are swapped, the browser rotated it and nothing more is done. If they match, the pixels are still raw and the transform is applied here. When the comparison is not possible, the control at the top lets you force the transform or skip it and look at the two results.
Re-encoding is the price
This is the honest limitation and it is not small. A canvas holds pixels, not a compressed file, so the only way out of a canvas is a fresh encode. The output is a new lossy compression of the decoded image, not the original bitstream with its metadata snipped out. At quality 92 that is difficult to see side by side and trivial to measure, and it compounds if you run the same file through twice.
Software that rewrites the container instead — leaving the compressed image data exactly as it was and deleting only the metadata segments — produces a byte-identical picture and cannot be built out of a browser canvas. If you are archiving, use that kind of tool. If you are about to post a photo to a forum, the difference will not survive the platform re-encoding it anyway.
Where to go next
To see the metadata without producing a copy, the EXIF viewer and image info read the same blocks and stop there. If you were going to shrink the file regardless, the image compressor and image resizer discard metadata as a side effect of the same canvas round trip, which means one pass instead of two. If the copy does come out sideways, rotate and flip will set it right.
Questions people ask
Is the cleaned copy identical to the original apart from the metadata?
No, and any tool that tells you otherwise while running in a browser canvas is wrong. The image is decoded to raw pixels and compressed again, so you get a new lossy encode. Quality 92 keeps that far below what most people can see, but it is a real loss and it stacks if you repeat it. A byte-identical strip means editing the container without touching the compressed data, which needs desktop software.
Why did my photo come out sideways?
Because the rotation lived in the EXIF orientation flag rather than in the pixels, and stripping the metadata took the flag away. This tool detects the usual case and bakes the rotation in first. If the result is still wrong, switch the orientation control between Auto, Force and Ignore — one of the three will match how your browser decoded the file — or fix the output with the rotate and flip tool.
Does this remove the location from my original file?
No. It produces a new file and downloads it. The original on your disk is untouched, coordinates and all. If the goal is that the location stops travelling, you have to actually replace or delete the original after checking the copy, and remember that any backup or cloud sync already holds the version with the metadata in it.
Do social platforms not strip this anyway?
The large ones generally do strip EXIF on upload, which is why the risk feels theoretical. It stays real everywhere else: email attachments, files dropped into chat as documents rather than photos, cloud storage share links, forum uploads, marketplace listings and anything you hand over on a USB stick. Those keep the file as it is.
What about PNG and WebP?
PNG can carry text chunks, a tIME timestamp, an eXIf chunk and an ICC profile, and this reads and reports them. WebP has its own metadata containers that are not parsed here, so the listing may be empty even when something is present. The cleaned copy is drawn from pixels in every case, so whatever the file carried does not survive the round trip regardless of whether it was listed.