EXIF Remover

Not on the lossless path. For JPEG, PNG and WebP the container’s block list is rewritten and the compressed image data is copied across byte for byte, so what comes out decodes to exactly the same pixels. The fallback is a different thing: anything the parser cannot open is redrawn on a canvas and re-encoded at 92% quality, which is a real generational loss, and a transparent image re-encoded as JPEG lands on a white background because JPEG has no alpha channel.

Phones write the sensor image in its native orientation and add an EXIF Orientation tag telling the viewer to turn it. Remove the metadata and that instruction goes with it, so the picture shows the way the sensor read it. When a file carries anything other than the normal orientation, a red warning appears above the results, re-run those files with the re-encode method, which draws the rotated image and bakes the rotation into the pixels.

The JFIF density header and the Adobe colour-transform block stay, because a decoder needs both of them.

No. Each file is read into an ArrayBuffer, the marker list is walked in JavaScript on your own machine, and the cleaned copy is handed back as a download. No request carries the photo, which is rather the point, given that the file you are stripping is the one holding your home coordinates and your camera’s serial number.

Yes. Drop in as many as you like and they are processed one after another into exif-removed.zip. Each output keeps its original extension with -clean added to the name, and two files that would collide inside the zip get a number appended instead of overwriting each other.