I Ran Remove Everything on My Travel Photos and 553 Bytes of Metadata Stayed
A few travel photos were about to go out, and the image metadata page has a default mode whose checkbox group is headed 全部清除, so I ran that one over every file. The page answered each time with one line about bytes saved. What stopped me was an impulse: I dragged the output back and read it again. That reread showed ev_exif.jpg going from 7746 bytes to 4711, minus 3035, with the EXIF tag count at zero, the embedded thumbnail at 0B and the XMP block gone. The metadata total had only come down from 3588 to 553.
Those 553 bytes split cleanly. The ICC segment under marker 0xE2 carries a 2 byte header and records 447; the PSD segment under 0xED records 106; together that is exactly 553. The 16 byte 0xE0 JFIF segment stays in place untouched and never enters this total. The cause is not hidden: the default mode offers 5 checkboxes and only XMP plus the JPEG comment were ticked, while Photoshop image data and the ICC colour profile box were both left empty. Only ticked segments get chopped.
So the habit I kept is a dull one: run the job, take the output, then drag that output back in and read it once more. The EXIF viewer page gives one line about bytes saved and stops there; it does not do this second pass for me, and the 553 is a number I found myself.
Location Only Does Not Chop Segments, It Rewrites the Structure
The second mode, whose button reads 只去掉位置信息, takes the same source image from 7746 to 6945 bytes, only 801 smaller. The page note claims 237 B saved, and that mismatch is no arithmetic slip: 237 counts only the deleted location tags, while this mode also lifts out the whole XMP segment carrying the position, whose body is 562 plus a 2 byte header, so 564. Put 237 and 564 together and you get exactly 801.
Drag the output back and 38 tags are still there, where the source image had 4 groups and 48 tags: ifd0 12, exif 24, gps 10, interop 2. The body serial number X100-0012345, the lens serial L-987654, the 96 byte manufacturer note, the user comment, the author and the copyright all remain, and the only entries that vanish are those 10 GPS ones. Removal has nothing to do with privacy flags: of the 48 tags only 9 carry [privacy], and the 10 GPS entries carry none, just one line on the group header saying the position is the most sensitive part and should be cleared. It reparses the TIFF tree rather than erasing segments.
Fig. 1: The same ev_exif.jpg measured twice. The default mode chopped 3 contiguous ranges and left a 4711 byte file whose metadata still adds to 553; the location mode only rewrites the structure, and of the 801 bytes that disappear the location tags are 237.
Whether the Embedded Thumbnail Goes Too Depends on Two Things
The panel carries a subtitle, EXIF 内嵌缩略图 · 清除 EXIF 会一起去掉, which reads like a promise that clearing EXIF takes the thumbnail along. That holds for the default mode and for nothing else. Whether one can be cut out at all depends on hard conditions: 0x0201 and 0x0202 must both exist and the compression scheme under 0x0103 must equal 6. On ev_exif.jpg, ev_exif.png and ev_exif.webp all three samples yield 1125 bytes whose header is FF D8 FF E0. ev_nothumb.jpg still carries 48 tags yet its thumbnail is 0B, and its APP1 is only 1198 bytes, 1149 short of the 2347 measured on ev_exif.jpg, which is exactly 1125 plus the two IFD entries describing it at 12 bytes each.
After the location mode finishes, those 1125 bytes are still in the output. The thumbnail lives in the same APP1 as the latitude and longitude but is not a location field, so the rewrite carries it over untouched. I know that only from my own reread; no note on the page mentions the thumbnail surviving.
PNG and WebP Take the Chunk Path: Pixels Untouched, Output Still Not a Pure Delete
The default path never re-encodes the picture, and across several containers the payload lines up. ev_exif.png goes from 4976 to 1888, minus 3088, and the 1729 bytes of IDAT are identical byte for byte. Rereading, the blocks left are IHDR, pHYs, pHYs, gAMA, iCCP, IDAT, IEND; text chunks fall from 3 entries to none, and metadata from 3148 to 60. The transparent sample ev_alpha_exif.png shrinks from 1439 to 207 and still reports colorType 6 with hasAlpha true.
WebP changes one thing more: its chunk table goes from VP8, EXIF, XMP, ICCP to VP8, ICCP, and the 2168 byte VP8 payload is identical byte for byte, yet the output refuses to line up with a pure delete. The first mismatch lands at offset 4, on the RIFF size field. ev_alpha_exif.webp from 1996 to 356 keeps VP8X, ALPH and VP8, the 48 bytes of ALPH were never touched, and on reread hasAlpha still reports false. Nothing was recompressed; this was a container edit, and container edits leave marks in header fields I had stopped watching.
| Sample | Source file | Default mode output | Location mode output | What a reread finds |
|---|---|---|---|---|
ev_exif.jpg | 7746B | 4711B | 6945B | metadata 553B / 38 tags |
ev_exif.png | 4976B | 1888B | 4161B | 60B, IDAT 1729B untouched |
ev_exif.webp | 5262B | 2376B | 4486B | ICCP 188B kept as is |
ev_anim.gif | 1396B | 1023B | not tested | pixel area 971B untouched |
ev_exif.tif | 58886B | no output | no output | one line: 该格式暂不支持无损清除。 |
Fig. 2: What the same mode leaves behind differs by container. JPEG keeps an ICC segment of 447 plus a PSD segment of 106, WebP keeps ICCP 188, PNG keeps only 60, and on GIF the comment chunk 41 and the XMP chunk 332 are both chopped.
One Coordinate Pair Prints Four Ways, and the Tag Names Line Up Wrong
Before clearing anything I have to confirm that I am reading a position, and the page makes that harder than it looks. The summary line shows 31.247667, 121.479133. The map link drops the raw double straight into the URL, #map=16/31.247666666666667/121.47913333333334. The degrees minutes seconds form keeps 2 decimals on the seconds, 31°14'51.6" 121°28'44.88". The altitude prints 52.6375 in the summary line and 52.638 in the tag table of the same file, while the out of range warning uses 5 decimals and shows 纬度 199.24767. Four precisions for one value.
More misleading is how names get chosen. Tag names are shared globally by id and never scoped per sub directory, so the interop group renders under GPS names, as 0x1 北纬/南纬 = R98 and 0x2 纬度 = 276, when the entries are really InteroperabilityIndex and InteroperabilityVersion. I reproduced that on all four containers. Reading is a rendering job with several passes over one stored value: when two lines disagree, both can be honest printings of the same number.
Q: How do I confirm the output is actually clean?
Drag the output back in and read it once more, because the clearing stage never rechecks its own work; it hands back one line about bytes saved. Running the location mode twice on the same file left the size at 6945 bytes with the second output byte for byte identical, and the second run answered only that there was nothing to clear under the current options.
Q: I want the shooting parameters kept and the identity fields gone, which mode?
The location mode leaves the body serial number, the lens serial L-987654, the 96 byte manufacturer note, the author and the copyright where they are, while lifting out the whole XMP segment that carries the position. The default mode is its mirror image: EXIF goes to zero, but the ICC and PSD segments I had never ticked stay behind, 553 bytes together.
Q: Nothing happened when I dropped a file in, is the extension to blame?
Support is decided by the magic number at the head of the file, and neither the extension nor the MIME type takes part. ev_jpg_named.png, 7746 bytes, was handled as JPEG, and since the download keeps the original extension the output is a JPEG stream wearing a .png name. TIFF is refused in both modes and produces no bytes at all, and HEIC only gets its boxes probed, so the formats listed on the page are not all formats that can be cleared. Anything past 40MB never reaches the list: 41951810 bytes is only 7470 over the line and it was skipped too, with one summary sentence at the end.