Remove metadata from a PNG

What we remove from a PNG

• tEXt, zTXt, iTXt — text chunks holding author, description, software and copyright. XMP lives here too.
• eXIf — a full EXIF block, GPS included. macOS writes one into every PNG it converts.
• tIME — the last-modification timestamp.
• caNv — Photoshop's canvas geometry, which reveals the original crop.
• prVW, orNT, dSIG — an embedded preview image, an editor's orientation hint, and a digital signature block.
• Anything after IEND — non-standard trailing data.

How we decide

PNG uses an allowlist rather than a blocklist: a chunk survives only if the image needs it to render. Everything else is removed by default — not because we've identified it as harmful, but because we haven't identified it as necessary, which is the safer default for a format where anyone can register a private ancillary chunk type and vendors regularly do.

This matters more than it sounds. Vendor-private chunks are exactly where unexpected data tends to live — Apple's own tooling has written private chunks like mkBF, mkTS and mkBS into PNGs, none of which are on any public list of "things to check for." An allowlist catches chunks like these automatically, without us having to have heard of that particular type first. Animation control chunks are the explicit exception: acTL, fcTL and fdAT are kept by name, so animated PNGs still animate.

One consequence worth knowing: because we only ever drop whole chunks and copy survivors verbatim, no CRC ever needs recomputing. Each chunk in the output still carries the exact checksum it arrived with, which is a quick way to confirm nothing partial or corrupted made it through — a decoder checking CRCs on the result will find every one valid.

What we deliberately keep

• iCCP, gAMA, cHRM and sRGB — the colour chunks that decide how the pixels are rendered, not who made them.
• acTL, fcTL and fdAT, the animation control chunks. Strip these from an APNG and you are left with a still frame.
• Every byte of pixel data, so the compressed image content is unchanged.

What a real dump looks like

A PNG's metadata chunks are plain, uncompressed text — unlike JPEG's binary TIFF-tag structure, you can read a PNG's tEXt chunk by opening the file in a text editor and scrolling past the binary noise. Screenshot tools on macOS write a tEXt chunk with the key XML:com.adobe.xmp holding a full XMP packet, timestamped to the second. Editors that support wide colour gamuts often add an iCCP chunk carrying an embedded colour profile that can run to several kilobytes — legitimate, worth keeping, and easy to mistake for junk if you're just counting chunk sizes.

The chunk layout, required ordering, and CRC validation are defined in the W3C PNG Specification (Third Edition), which is also where the allowlist this page uses comes from — the spec itself distinguishes "critical" chunks a decoder must understand from "ancillary" ones it may skip, and that boundary is exactly what we remove versus what we keep.

What survives common editors

Resizing a PNG in Preview or GIMP typically regenerates the file from scratch, which incidentally strips most ancillary chunks — a side effect of re-encoding, not a metadata-aware feature. Photoshop is the opposite: it preserves and actively writes to tEXt and iCCP chunks across saves, so a PNG that's been through several rounds of editing can carry a longer edit history than the photo it started from. Screenshot-to-PNG pipelines (macOS's⌘⇧4, most Linux screenshot tools) write the capture timestamp and often the source application name, which is how a "harmless" screenshot ends up revealing what software you were using and when.

Compare that to the other common image formats: a JPEG hides device serials and GPS in a binary EXIF block most people can't read without a tool, while a bare BMP has almost nowhere to put metadata at all. PNG sits in between — its metadata is trivially readable once you know where to look, but screenshot and editing tools write to it constantly, so what actually ends up in a given file varies far more than the format's simplicity would suggest. See the image formats hub for the full comparison.

Cleaning something else?

Camera photos carry far more than a screenshot ever will — see JPG for GPS coordinates, camera serials and a hidden thumbnail. TIFF files hide data at absolute byte offsets that are even harder to find by hand. For a whole folder at once, the batch cleaner has no file limit. Cleaning a screenshot specifically? See what a screenshot's metadata actually contains first.