EXIF Remover

Who needs this and why

The first scenario is publishing. A photo from a holiday or a birthday goes somewhere public, and the coordinates of your flat and the date go with it. The second is selling and renting property: a listing for an apartment whose EXIF holds the exact address can be found by a coordinate search, and those photos are taken on a phone. The third is reports and contractors: photos from a site end up in email, in a CRM, in the cloud, and the company later discovers private home addresses of other people inside its own corporate folder.

There is a separate class of task: preparing images for a website. In a product catalogue or a photography portfolio of twenty thousand files, every extra kilobyte adds up to tens of megabytes you pay to store and hand to visitors. Removing metadata cuts both the weight and the leak. Nearby tasks have their own tools, such as the WebP to JPG converter and the image resizer — but remember that those really do re-compress the picture and change quality, unlike this one.

• Publishing personal shots without geotags and dates
• Property listings where the address must not leak
• Corporate photo archives and contractor reports
• Catalogues and portfolios where every byte of each file counts
• Preparing shots for upload to third-party services

Where people go wrong when cleaning metadata

The first mistake is assuming that a cleaned photo becomes anonymous. Metadata and frame content are two different things. Removing EXIF takes away the date, the model and the coordinates, but the person in the shot, the plate of the car and the sign across the street stay exactly where they are. The second mistake is cropping the picture to «remove» a watermark: cropping the image removes part of the picture, not the signature, and leaves an ugly border. The third is confusing EXIF with the ICC profile — one holds the shooting history, the other controls colour and should not be removed. Picking a colour is a separate job, and colour lookup by name does that one.

The fourth mistake is forgetting about orientation and getting a picture that lies on its side. The fifth is cleaning the only copy of a shot and only then realising that it held the only correct orientation. The sixth is trying to «clean» a file that has already been cleaned: the tool will honestly say there is nothing to remove, and that is not a failure but a result. And the seventh is expecting the file to come out the same size. It will be smaller, but it will not be byte-identical to the original.

• Believing that removing EXIF also removes people and plates in the frame
• Trying to erase a watermark by cropping the picture
• Deleting the ICC profile along with the EXIF
• Forgetting the orientation tag and ending up with a sideways shot
• Cleaning the only copy of a file without a backup

How the file is parsed

Parsing starts with the signature: the first two bytes have to read as FFD8, otherwise this is not a JPEG. From there the file is read as a sequence of segments. Every segment has a two-byte marker and a two-byte length, and the length includes those four bytes. Until the marker FFDA is reached, the segments are simply listed. APP0 is JFIF, APP1 is EXIF or XMP, APP2 is the ICC colour profile, APP13 carries Photoshop and IPTC data, and FFFE is a free-form comment.

Then the interesting part begins, the contents of the EXIF. The header «Exif» and the two zero bytes separate it from the rest of APP1, and after them comes the TIFF structure: the bytes II or MM set the byte order, the number 42 serves as a check, and the next four bytes point to the first IFD. The table starts with a count, followed by twelve-byte entries: tag number, type, number of values, and four bytes where a short value sits directly and a long one is addressed by offset. The pointers 0x8769 and 0x8825 open the nested EXIF and GPS tables. The date, the shooting parameters and the coordinates all come out of those.

The whole parse runs in the browser on plain bytes, with no third-party libraries and nothing sent anywhere.

Orientation, weight and other file formats

Orientation forces a choice: either keep the tag, or accept that portrait shots have to be rotated by hand. Sometimes the better order of operations is to bring the frame into shape in an editor first, and then metadata can be removed without worrying about tag 0x0112. As for weight, the picture is simple: cleaning removes tens of bytes or kilobytes, while real compression removes tens of percent. For that there is the WebP to JPG converter — which really does re-compress the image, unlike metadata cleanup. Raster icons and logos are a different story, and the SVG to PNG converter covers those.

Other formats store metadata differently. In HEIC and HEIF the container writes it, which is a separate story covered in opening HEIC photographs. In camera RAW files the metadata cannot be separated from the data, and removing EXIF there means losing the shooting parameters wholesale. We work only with JPEG and PNG, the two formats where cleaning is safe and predictable. One detail about PNG: its EXIF lives in a dedicated eXIf chunk rather than in an APP1 segment, even though the principle of cutting out a metadata block and leaving everything else alone is the same.

• Orientation: keep tag 0x0112 or rotate the shot by hand
• Weight: cleaning removes kilobytes, compression removes tens of percent
• HEIC and HEIF: the container writes the metadata, a different parse
• RAW: the metadata cannot be separated from the captured data
• PNG: EXIF sits in an eXIf chunk, not in an APP1 segment