Photos carry a hidden payload: the EXIF block records your camera model, capture time, editing software — and, on most phones, GPS coordinates of where you stood. Whether a converter strips or preserves that block is a privacy property, so instead of asserting it, we measured it.
Method. We built a JPEG fixture with a precisely known EXIF payload: one APP1 segment of exactly 67 bytes containing a camera make tag and Orientation=6 (rotated). We ran it through each conversion path on this site in Chromium 147 (2026-08-16), then scanned every output's bytes for APP1/EXIF markers — the same check our automated test suite performs. Fixture and method are reproducible from the repository.
| Path | Output | EXIF in output | Output size |
|---|---|---|---|
| Compress (default) | JPEG | None — stripped | 214,282 B |
| Compress + "keep EXIF" on | JPEG | Present — original APP1 spliced back | 214,349 B (= 214,282 + exactly 67) |
| JPG → PNG | PNG | None — no eXIf or tEXt chunks at all | 2,334,980 B |
| HEIC → JPG | JPEG | None — HEIC container metadata not carried over | 205,748 B |
| RAW → JPG (NEF) | JPEG | None — camera's embedded JPEG is metadata-bare | 981,911 B |
The 67-byte line is the satisfying one: the "keep EXIF" output is byte-for-byte the stripped output plus the original APP1 segment, nothing more. No re-interpretation, no rewriting — the original metadata block, resurrected intact, with one deliberate exception below.
Why stripping is the default
Every image tool here decodes your file to raw pixels on a canvas and re-encodes from those pixels. The browser's encoder writes image data and nothing else — no APP1, no XMP, no maker notes. So metadata removal isn't a feature we added; it's a structural consequence of pixel-level re-encoding, which is why it holds across every format path in the table. For the common privacy case — "share the photo, not the coordinates" — the default does the right thing without a checkbox.
The orientation trap in "keep EXIF"
Splicing the original EXIF back has a subtle bug waiting in it, and it's worth documenting because many tools get it wrong: canvas decoding already applies the EXIF rotation to the pixels. If you then reattach the original block with Orientation=6 intact, every EXIF-aware viewer rotates the image again — sideways photos. Our splice rewrites the Orientation tag to 1 ("as stored") while leaving everything else untouched, which is why the fixture's Orientation=6 goes in and Orientation=1 comes out.
Where GPS lives — and when it dies
GPS coordinates are not a separate block: the GPS directory lives inside the same APP1 segment as the rest of EXIF. That has a clean consequence: every "None" row in the table means location data is gone too, and the "keep EXIF" toggle keeps location along with the rest — it's all one segment. If you want the camera settings but not the coordinates, strip everything (the default) — selective redaction is a planned refinement.
Honest limits
- Our scan targets EXIF APP1 — but the canvas encoder drops all ancillary segments (XMP, ICC profiles, maker notes, JPEG comments), so stripped outputs carry no metadata of any kind beyond the format's mandatory header.
- Color-managed workflows note: dropping the ICC profile means wide-gamut images are interpreted as sRGB after conversion.
- File name and file-system timestamps are outside the file — no converter can strip those; check what you're uploading alongside the pixels.
Related reading: how to verify none of this ever leaves your device, and the quality-vs-size measurements.