Yes, you can remove metadata without losing image quality. Metadata is stored in separate blocks of the file, apart from the compressed pixel data, so a tool that simply deletes those blocks leaves every pixel exactly as it was. Quality is lost only when a tool decodes the image and saves it again in a lossy format like JPEG, which many editors and converters do without telling you.
The difference between those two approaches, removing segments versus re-encoding, is the whole story. This article explains how each works, which common tools fall on which side, and how to verify that your cleaned photo is pixel-for-pixel identical to the original.
Where metadata lives inside an image file
Image formats are containers. The pixels are stored in one part of the file; descriptive information is stored in other, clearly labeled parts. Software that understands the container can remove the labeled parts without opening the pixel data at all.
JPEG: marker segments
A JPEG file is a sequence of segments, each starting with a two-byte marker. Metadata sits in "application" segments near the start of the file, before the compressed image data:
| Segment | Usually contains |
|---|---|
| APP1 | EXIF (camera, dates, GPS, embedded thumbnail) and, in a separate APP1, XMP |
| APP2 | ICC color profile; on some cameras, Multi-Picture Format data |
| APP13 | Photoshop resources, including the legacy IPTC block |
| APP11 | JUMBF boxes, used by C2PA Content Credentials |
| COM | Free-text comments |
The actual picture is in the quantization tables, Huffman tables and the entropy-coded scan that follows. Deleting an APP segment does not change a single byte of the scan.
PNG: chunks
A PNG is a series of chunks. Pixel data is in IDAT chunks; metadata uses separate chunk types such as eXIf (EXIF), tEXt, zTXt and iTXt (text, including XMP), tIME (last modification time) and iCCP (color profile). The W3C PNG specification defines each one.
WebP: RIFF chunks
WebP uses a RIFF container. The image is in a VP8 (lossy) or VP8L (lossless) chunk, while metadata goes in EXIF, XMP and ICCP chunks, announced by flags in a VP8X header. Removing a metadata chunk only requires updating those flags and the container size.
If you want to know which standard each kind of metadata comes from, see EXIF vs IPTC vs XMP.
How lossless metadata removal works
A lossless remover reads the container, copies the segments or chunks that make up the image, skips the ones that hold metadata, and writes a new file. The compressed image data goes through byte for byte. Nothing is decoded, so nothing can be degraded.
Two consequences are worth knowing:
- The file gets a little smaller, not a lot smaller. The size drops by roughly the amount of metadata removed. A phone photo might lose a few kilobytes; a photo from a camera with large maker notes and a full-size preview image can lose much more.
- The result is identical when decoded. Any viewer will produce exactly the same pixels from the cleaned file as from the original, because it decodes exactly the same data.
Why re-encoding a JPEG loses quality
JPEG is a lossy format. To save a JPEG, an encoder converts the colors, often halves the resolution of the color channels (chroma subsampling), splits the image into 8×8 blocks, transforms each block into frequency components and then rounds those components using a quantization table. The rounding is where information is thrown away, and it cannot be recovered.
When an app opens a JPEG, it decodes it into plain pixels. When it saves, it runs the whole lossy process again on pixels that already carry the first round of compression errors. That is generation loss. Its effects:
- Blocking and ringing become more visible, especially around sharp edges, text and fine patterns.
- Color edges soften if color is subsampled again.
- Changing the quality setting between saves, or cropping so the 8×8 grid shifts, makes the damage worse than re-saving with identical settings.
- Quality 100 is not lossless. It reduces the rounding but does not eliminate it, and it often makes the file larger than the original.
One re-encode at a high quality setting is usually hard to see on a phone screen. The problem is that it is invisible, and that it accumulates: a photo that gets edited, cleaned, resized and uploaded can be recompressed four or five times before anyone looks at it closely.
PNG and WebP are different
PNG compression is lossless, so re-encoding a PNG keeps the same pixels, but it can still change bit depth, drop the color profile or produce a larger file. WebP has both modes: re-encoding lossless WebP keeps the pixels, while re-encoding lossy WebP has the same generation-loss problem as JPEG.
Which methods are lossless and which re-encode
| Method | Re-encodes the image? | Notes |
|---|---|---|
ExifTool (exiftool -all= photo.jpg) | No | Rewrites metadata only. Also removes the ICC profile unless you add it back. |
jpegtran (jpegtran -copy none) | No | Lossless transform of JPEG data; -copy none drops all extra markers, including the color profile. |
| Our tool, "Keep same format" | No | Removes metadata segments and chunks; keeps the ICC profile and orientation flag. |
| Our tool, convert to another format | Yes | Re-encodes at the quality you choose and applies the rotation to the pixels. |
ImageMagick (-strip, mogrify) | Yes, for JPEG | Decodes and writes a new JPEG; convenient for batches but not lossless. |
| Photo editor "Save As" or "Export" | Yes, for JPEG and lossy WebP | Photoshop, GIMP and similar apps always encode a new file. |
| Taking a screenshot of the photo | Yes | Also limits the image to your screen resolution and can add interface elements. |
| Uploading to most social networks | Usually | Large platforms generally resize and recompress uploads anyway. |
That last row matters for priorities. If a photo is going to be recompressed by the platform you post it to, the quality of your cleaning step makes little difference. Where lossless removal really counts is when you share the original file: email attachments, client deliveries, prints, stock or portfolio sites, archives and your own website.
For command-line details, including how to keep the color profile with ExifTool, see the ExifTool cheat sheet.
The two pieces of metadata you should keep
"Lossless" in the strict sense means the pixel data is unchanged. But two metadata items affect how those pixels are displayed, and deleting them can make a perfectly preserved photo look worse.
The ICC color profile
Recent iPhones and many cameras record in a wide color space such as Display P3 and embed a profile saying so. Remove the profile and software assumes standard sRGB, so colors look duller or shifted, especially reds and greens. A profile contains color math, not personal information, which is why it is safe to keep. Our article on ICC color profiles explains the details.
The orientation flag
Phones often store the pixels in the sensor's native orientation and add an Orientation tag telling viewers to rotate the image for display. A remover that deletes that tag without rotating the pixels produces a sideways photo. Keeping the flag avoids it; the fix for already-broken files is covered in why photos turn sideways after removing metadata.
This is why our metadata remover keeps exactly these two items in its default "Keep same format" mode and removes everything else, including GPS, camera make and model, serial numbers, dates, software, maker notes, embedded thumbnails, XMP, IPTC, comments, PNG text chunks and C2PA data.
How to verify that quality was not touched
You do not have to take any tool's word for it. Three checks, from quick to rigorous:
- Compare file sizes. A lossless cleaning shrinks the file by roughly the size of the metadata. If a 4 MB photo becomes 1.5 MB, it was recompressed.
- Compare pixel data hashes with ExifTool. Recent versions of ExifTool can compute a hash of the main image data only, ignoring metadata and thumbnails (the ImageDataHash tag). If both files print the same hash, the image data is identical.
exiftool -ImageDataHash original.jpg cleaned.jpg - Compare decoded pixels with ImageMagick. The
AEmetric counts pixels that differ;0means none do.magick compare -metric AE original.jpg cleaned.jpg null:
If the orientation flag was removed and the pixels rotated, the comparison will fail even though no quality was lost, so compare files that are oriented the same way.
When converting (and re-encoding) is worth it
Re-encoding is not always bad. Sometimes converting is the better choice, as long as you do it once, from the best source file, on purpose.
- A huge PNG photo. Photos saved as PNG can be many times larger than a high-quality JPEG or WebP. Converting makes them practical to share, at a small, controlled cost.
- Apps that ignore the orientation flag. Some older software and upload forms show photos sideways. Converting applies the rotation to the pixels, so the photo displays correctly everywhere.
- A format the recipient needs. Some forms accept only JPEG; some web workflows prefer WebP. Our comparison of JPEG vs PNG vs WebP helps you choose.
- Doubts about hidden data in the file structure. Encoding a new file from the decoded pixels leaves behind anything that is not part of the visible image.
When you convert, pick a high quality setting for photos and avoid converting text-heavy screenshots or graphics to JPEG, where artifacts show up quickly. Remember that converting to JPEG replaces transparency with white.
A quality-safe workflow
- Clean the original file, not a copy that has already been edited and re-saved several times.
- Use a lossless method (same format) unless you have a specific reason to convert.
- Keep the color profile and orientation flag.
- If you convert, convert once, and do your edits before that step.
- Check the size difference, and run a hash or pixel comparison when quality really matters.
Done this way, removing metadata is purely a privacy step: the people you share with see exactly the photo you took, and nothing else.