gizmobench

EXIF Remover

Open a photo and the page shows you two panes: what the file is carrying now, and what is left after the metadata goes. The EXIF block with the camera, the date and the GPS fix, an XMP packet, a Photoshop or IPTC block, a JPEG comment, and the text, eXIf and tIME chunks of a PNG are all lifted out, and every one of them is named in a table with its size and what it holds before it goes. What is different here is the other half of that promise. The compressed picture is never decoded and never encoded again: the file is copied through with gaps where the metadata sat, so the bytes a decoder turns into pixels are the same bytes they were, and the page checks that by comparing them rather than by asserting it. The colour profile is the one block you decide about, because dropping an ICC profile can change how a picture looks on a wide-gamut screen, and it is kept unless you switch it off. The structural blocks a decoder needs stay too: the JFIF header, the Adobe colour transform, a PNG's colour chunks and an animated PNG's frames. Nothing is uploaded, there is no account and no size limit is imposed, since the file never leaves the tab it was opened in.

before11 tags
Make      Apple
Model     iPhone 15 Pro
GPS       42.387583, -71.099500
Taken     2026:07:14 11:02:33
Software  Photos 9.0
Comment   Shot on the way home. Do not post.

Blocks    APP1, COM
Tags      11
after0 tags
no EXIF
no GPS
no comment

pixels unchanged
no colour profile in this file
11 tags gone, 294 bytes lighter

Showing a sample. or drop one here. It stays in this tab.

Never uploadedNo accountNo re-encodingAny file size
Removed
11 tags
GPS
Gone
Pixels
Unchanged
Profile
none stored

The GPS fix is gone.It read 42.387583, -71.099500, and the cleaned file carries no coordinates at all. Removed 11 tags in 2 blocks, 294 bytes in all. The compressed picture is byte for byte what it was.

Removed 11 tags in 2 blocks, 294 bytes in all. The compressed picture is byte for byte what it was.

Every block, and what happened to it

BlockHoldsSizeResult
APP1EXIF: Apple iPhone 15 Pro, GPS 42.387583, -71.099500, 2026:07:14 11:02:33256 bytesremoved
COMComment: Shot on the way home. Do not post.38 bytesremoved
APP0JFIF header: pixel density and aspect18 byteskept, a decoder reads the picture's density from it

Everything not listed as removed is copied through in the order it arrived, the compressed picture included. The file that comes back is 161 bytes against 455 bytes going in.

  • Photo with GPSEXIF, a fix and a comment
    all removed, pixels identical
  • Keep colour profileICC profile present
    profile kept, rest removed
  • Already cleana PNG with no metadata
    says so, file unchanged

The photo with gps sample stays on the stage until you open a file. The three samples are small files this page writes itself, byte by byte, rather than photographs: one carries a full EXIF block with a GPS fix, one carries a stand-in colour profile, and one carries nothing. JPEG and PNG are cleaned. No size limit is imposed, since nothing is uploaded: the ceiling is the memory of the browser you are using.

Where your file goes. Nowhere. It is read by this page, in this tab, with a FileReader, and the cleaning happens in your own browser: there is no upload, no account and no request of any kind. The picture and its metadata are never written to storage either. The only things this page remembers are whether you keep colour profiles and which sample you last looked at, and the Start over button above forgets both.
Accuracy. The compressed pixel data is copied through byte for byte, so the picture is not re-encoded and loses no quality. What is removed is the metadata blocks, listed before and after, and the colour profile stays only if you ask for it.

Common questions

Does removing EXIF reduce the quality of the photo?
No, and that is the point of doing it this way. A JPEG is a chain of segments and a PNG is a chain of chunks, with the metadata sitting beside the compressed picture rather than inside it. So this tool copies the file through and leaves gaps where the metadata blocks were: the quantisation and Huffman tables, the frame header and the compressed scan of a JPEG, or the header, palette and every IDAT block of a PNG, are written out untouched. Nothing is decoded and nothing is re-encoded, so there is no second round of JPEG loss and no resampling. The Pixels cell in the readout is not a slogan either: the page pulls the compressed picture out of the file that went in and out of the file that came back, compares them byte for byte, and says Unchanged only when they match.
Is my photo uploaded anywhere?
No. The file is read by this page with a FileReader and cleaned in your own browser, so there is no server in this, no account to make and no request of any kind. Sending a photo to a website in order to remove the coordinates from it would be a strange way to keep them private, which is why this tool does not. The picture and its metadata are never written to local storage either. The only two things the page remembers are whether you keep colour profiles and which sample you last looked at, and the Start over button above the tool forgets both.
Does it remove the GPS location from a photo?
Yes. The GPS fix lives in a sub-directory of the EXIF block, and the whole EXIF block is removed, so the coordinates, the altitude, the time of the fix and the direction the camera was pointing all go with it. Before they go, the page reads them out in decimal degrees to six places so you can see exactly what the file was carrying, and the GPS cell in the readout says Gone once the cleaned file has been read back and confirmed to hold no coordinates. That check is done on the output bytes, not assumed from the input.
What exactly is removed, and what is kept?
Removed from a JPEG: the EXIF block in APP1, including its thumbnail and GPS directories, an XMP packet, the Photoshop and IPTC block in APP13, every comment segment, and the other application blocks a camera or an editor writes. Removed from a PNG: tEXt, zTXt and iTXt chunks, an eXIf chunk, the tIME modification stamp and private ancillary chunks. Kept, because a decoder reads them and dropping them would change the picture rather than clean it: the JFIF header, the Adobe colour transform, a PNG's transparency, gamma, chromaticity, sRGB, background and pixel-size chunks, and the frames of an animated PNG. Every block that goes and every block that stays is listed under the stage with its size and the reason. Anything sitting after the end of the picture, past a JPEG's end-of-image marker or a PNG's IEND chunk, is not a block this tool can take apart: it is copied through and flagged in a note rather than guessed at.
Why would I keep the colour profile?
An ICC profile describes a colour space, not a person or a place: it tells a screen how to show the colours in the file. Remove it from a picture that was edited in Display P3 or Adobe RGB and browsers will read the numbers as plain sRGB, which usually shows up as flatter, duller colour. So the profile is kept by default and the toggle in the after pane removes it with everything else when you would rather have the smallest possible file, or when the profile itself came from a workflow you do not want to advertise. The choice is remembered for next time, and a sub-page or a preset can open the tool with either setting.
Which files can it clean, and how large can they be?
JPEG and PNG. A HEIC, WebP, AVIF, TIFF, GIF or PDF is named and refused rather than half rewritten, because those store metadata in structures this tool does not take apart, and a partly cleaned file would be worse than none. No size limit is imposed, because nothing is uploaded and there is no compute to pay for: the practical ceiling is the memory of the browser you are using. The metadata itself sits in the first few kilobytes of a photo, so cleaning a large file is no slower than cleaning a small one.
What happens to a damaged file?
It is refused with the reason, and your original is not touched. Every length in a JPEG or a PNG was written by whatever made the file, so each one is checked before it is followed: a segment that says it is longer than the bytes that remain, a chunk that claims more data than the file holds, a chunk length past PNG's own ceiling, a PNG with no IEND, or a file that holds no image data at all each stop the strip and say which byte the trouble is at. An EXIF block whose internal offsets point outside itself is reported as unreadable and removed whole, which is the safe outcome for a block that is leaving anyway.
How do I check that the metadata is really gone?
Open the cleaned file again with this page and read the before pane: a clean file reports no EXIF, no GPS and no comment, and its tag count is zero. The page already does that for you, since the after pane is produced by reading the cleaned bytes back rather than by subtracting what was removed. One thing no tool can strip from inside the file is the date your operating system stamps on it when it is saved, because that lives in the file system rather than in the picture.

The compressed pixel data is copied through byte for byte, so the picture is not re-encoded and loses no quality. What is removed is the metadata blocks, listed before and after, and the colour profile stays only if you ask for it.