Image privacy research

PNG Text Chunks: Real Metadata You Never Notice

PNG has a reputation for being metadata-light, which is only partly earned. The format defines three text chunk types that store keyword and value pairs, and they are ordinary chunk data that a writer can add without affecting rendering. Our generator writes three such chunks and our analyzer recovers all three keywords by parsing the chunk structure, which shows both that the data is real and how to detect it.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

PNG is often assumed to carry no metadata, but it has a text chunk system. What can actually be stored there, and how do you detect it?

This research describes PNG text metadata using this repository's own generated fixture. It does not claim a particular share of real PNG files carry text chunks and does not describe any converter's behaviour.

Try it on the anchor product: BeanNest Tools /image/.

The three text chunk types

PNG defines tEXt for uncompressed Latin-1 text, zTXt for compressed text, and iTXt for international text with language tags. A parser must treat all three as text metadata. Our analyzer classifies each as text and extracts the keyword from the chunk data.

How our fixture differs from the clean one

The clean PNG in our corpus has three segments: the header, the compressed image data, and the end marker. The fixture with text has six segments, adding three text chunks. The analyzer reports a metadata segment count of zero for the clean file and three for the text file.

The recovered keywords

The analyzer reports the keyword list Author, Software, Comment for our fixture, produced by reading each chunk's keyword field up to its null terminator. These are the actual keyword bytes in the file, not a fixed list of names the analyzer knows about.

Why PNG metadata is easy to overlook

Text chunks are interleaved with image chunks and carry no visible marker in the rendered image. A viewer shows the picture and nothing else. Detection therefore requires walking the chunk sequence, which is what the analyzer does and what a size-based or rendering-based check would miss.

The size contribution

The three chunks add 117 bytes to a 6934-byte file, 1.7 percent. In this corpus the text metadata is real but small. The guide states the small contribution rather than implying that PNG metadata is usually a large share, because our measurement does not support that.

What a detection claim requires

Saying a PNG carries no metadata is a claim about chunk contents. It can only be supported by walking the chunks and reporting what was found. Our analyzer reports segment counts, metadata counts, and keyword lists, which is the evidence a detection claim needs.

The structure of a tEXt chunk

A tEXt chunk's data is a keyword, a null terminator, and the text value, with no separate length for either part. The analyzer finds the null byte and treats everything before it as the keyword and everything after as the value. That is why the recovered keyword list for our fixture reads Author, Software, and Comment: those are the literal bytes before each terminator, not a list the analyzer was given in advance.

Why zTXt and iTXt need the same treatment

The compressed variant stores its value deflated, and the international variant adds a language tag and a translation keyword before the value. All three carry a keyword in the same leading position, so a classifier that treats them as text metadata without decompressing can still recover the keyword. Our analyzer classifies all three as text chunks, which is why the metadata segment count is correct even though only the uncompressed variant is used in the fixture.

What a viewer will never show you

PNG text chunks do not render. A viewer opens the file, draws the image chunks, and ignores the text. Nothing in the interface indicates that author or software information is present. This is the same invisibility that makes EXIF easy to overlook in a JPEG, but it is more complete in PNG because there is no equivalent of a visible metadata panel in most editors.

How to check a file yourself

The analyzer's PNG path reports the segment count, the metadata segment count, the metadata byte total, and the keyword list. Running it on a file answers the detection question directly and shows the byte cost. That is the same procedure the guides use, so the published numbers can be reproduced on any PNG rather than only on the committed fixtures.

Why keyword recovery proves detection

Reporting that a file contains three text chunks establishes a count. Reporting that those chunks carry the keywords Author, Software, and Comment establishes that the parser read inside them. The second is a stronger claim, and it is only possible because the parser locates each chunk's null terminator and reads the bytes before it. A parser that inferred keywords from a fixed list would produce the same output on a file it had not examined, which is the difference between detection and assumption.

How the clean and text fixtures differ

The two PNG files differ only by three inserted chunks. Everything else, dimensions, bit depth, colour type, and the compressed pixel data, is identical because the generator produces them from the same code path. That control makes the difference in the analyzer's output attributable entirely to the inserted text, so the metadata count of zero versus three is a clean comparison rather than a coincidental one.

Why text metadata is easy to overlook

Text chunks do not render, so a viewer shows the picture and nothing else. Most editors do not surface them, and file size does not hint at them because they are a small fraction of a normal image. Detection therefore requires walking the chunk sequence, which is what our analyzer does and what a rendering-based or size-based check would not do. The invisibility is the reason a detection claim needs structural evidence.

How the size contribution compares with JPEG

The three chunks add 117 bytes to a 6934-byte file, a share of one point seven percent. A comparable EXIF block in a JPEG would be a similar absolute size, but the JPEG in this corpus is far smaller so the share is much higher. The absolute metadata size is comparable across formats while the share is not, which is another reason a published share figure must name its file.

What a detection claim requires in practice

Saying a PNG carries no metadata is a claim about chunk contents, and it can only be supported by walking the chunks and reporting what was found. Our analyzer reports the segment count, the metadata segment count, the byte total, and the keyword list, which together answer the presence question and the content question. That combination is what a checkable detection claim needs.

How the keyword and value are separated

A tEXt chunk's data begins with the keyword, followed by a single null byte, followed by the text value. There is no length field for either part. The parser therefore searches for the null byte and treats the bytes before it as the keyword. That is why the recovered list reads the literal keywords rather than names the parser knew in advance, and it is why the same code handles any keyword a writer chooses.

Why three chunks were chosen

Author, Software, and Comment are the keywords an editor or an export pipeline most commonly writes, so recovering them shows the parser working on realistic keys rather than on synthetic ones. Three chunks also make the metadata segment count visibly different from the clean file's zero, which makes the comparison unambiguous. A single chunk would have worked but would have shown less about how the count accumulates.

What the parser does with the compressed variant

The compressed text variant stores its value deflated and the international variant adds language tags before the value, but all three place the keyword in the same leading position. The parser therefore recovers the keyword from any of them without decompressing, which is why the classifier treats all three as text metadata. The corpus uses the uncompressed variant, and the guide states that the other two are handled by the same keyword rule rather than claiming to have measured them.

How this check differs from a size check

A size check would report that the file changed by some number of bytes and would say nothing about what was present. The structural check reports the count and the keywords, which answers both the presence and the content question. For a metadata claim those are the two questions that matter, which is why the guide directs a reader to the structural check.

First-party evidence and provenance

How we checked this

We wrote four small images with this repository's own generator, then parsed each file's container segments and EXIF tag directory with this repository's own analyzer. Both are dependency-free and deterministic, so the same commands reproduce the same byte counts. For this guide we walked the PNG chunk sequence in both the clean and the text fixture and recovered each text chunk's keyword, which demonstrates detection by parsing rather than by pattern matching.

Method: We wrote four small images with this repository's own generator, then parsed each file's container segments and EXIF tag directory with this repository's own analyzer. Both are dependency-free and deterministic, so the same commands reproduce the same byte counts.
Environment: Node.js on a desktop workstation. The images are generated from code in this repository; no camera photo, third-party file, or network resource was used.
Captured: September 20, 2026
Reviewed by: BeanNest Studio

Repository evidence artifacts:

tools/research-evidence/image/analysis-2026-09-20.json
tools/research-evidence/image/README.md