Images & photos · Image Metadata Privacy Tool
Where PNG Files Hide Metadata: tEXt, iTXt, zTXt and eXIf Chunks
· How it works
image-privacy file-formats browser-processing
PNG has no EXIF tradition, so people assume it carries nothing, yet it can hold text chunks with software names and comments, XMP packets and, since 2017, a dedicated eXIf chunk. This post explains how a browser tool finds and removes them.
The 'clean' screenshot that named your editing software — why PNGs from editors and screenshot tools can carry more than pixels
A screenshot can look visually plain while a tEXt chunk names its author or writing software. PNG metadata is not confined to one EXIF tradition: text, timestamps and a TIFF-shaped EXIF payload can each occupy separate chunks. The inspector exposes ordinary tEXt contents and identifies the other supported metadata chunks before a cleaned copy is built.
PNG anatomy in one page — the eight-byte signature, the length-type-data-CRC chunk layout, and how the case of the chunk name marks it critical or ancillary
A PNG begins with an eight-byte signature followed by chunks containing a length, four-character type, payload and CRC. Image dimensions live in IHDR, compressed pixels in IDAT and the file ends at IEND. That labelled structure lets the cleaner remove whole metadata chunks and copy every surviving chunk verbatim, so it never has to decode pixels or recompute a CRC.
The text chunks: tEXt, zTXt and iTXt — Latin-1 keyword pairs, compressed text, UTF-8 international text, and the 'XML:com.adobe.xmp' keyword that hides a full XMP packet
The tEXt form stores a keyword and plain text, so the reader can show both. zTXt contains compressed text and iTXt carries international text; this implementation lists their keyword but does not decompress their contents. Both are nevertheless removed as whole chunks, which avoids pretending that an unread value was absent merely because the table could not display it.
eXIf, tIME and the rest — the 2017 eXIf chunk that carries a TIFF-structured EXIF block, the tIME modification stamp, and which ancillary chunks affect display rather than privacy
The eXIf chunk carries a TIFF block that can contain the same camera, time and GPS directories parsed in JPEG or WebP. The tIME chunk records when the file was last written and is reported as a timestamp. Other ancillary chunks are not automatically private: their effect matters, so classification is based on the documented support matrix rather than on whether a chunk is optional.
How a stripper decides what to drop — removing metadata chunks while keeping IHDR, PLTE, IDAT, IEND and the chunks that govern colour and transparency
The stripper drops eXIf, tEXt, zTXt, iTXt and tIME. It keeps gAMA, cHRM, sRGB and iCCP colour information, pHYs density and rendering chunks such as tRNS, bKGD and sBIT because removing them could alter display. This is a deliberate boundary: cleaning means removing the named metadata categories, not deleting every ancillary chunk.
Worked example: inspecting an exported PNG — listing what it carries before and after stripping and confirming the image decodes identically
For an exported PNG, inspect the field table first: a readable Author tEXt value appears directly, while compressed text appears only by keyword. After removal, the report lists each dropped type and the cleaner can re-read the output. The implementation test also compares IDAT before and after and requires identical bytes, proving that a smaller file was not achieved by recompressing the picture.
What this does not cover — APNG animation and colour-management decisions; the tool page documents exactly which chunk types it removes
Animated chunks and colour profiles are outside the privacy reader’s detailed interpretation, and a colour profile can itself carry a description string even though it is kept. The tool also does not detect information hidden in IDAT or support every image container. Use the removed and kept lists as the exact statement of scope instead of treating an empty metadata table as universal clearance.
Takeaway: PNG metadata is optional, so it can go — the Image Metadata Privacy Tool inspects and strips PNG metadata without touching the compressed image data
PNG metadata is optional container material, so the supported chunks can be removed without rebuilding the image. The safe workflow is inspect, remove, verify and download the new -no-metadata copy while preserving the original. That gives a designer a predictable result: text, EXIF and write-time chunks leave; colour, transparency, density and compressed image data remain.