Image privacy research

JPEG and PNG Store Metadata in Opposite Ways

JPEG and PNG solve the same problem with opposite designs. JPEG writes metadata as segments that precede the compressed image data, located by marker bytes. PNG writes metadata as named chunks interleaved with image chunks, located by walking a length-prefixed sequence. The structural difference explains why our analyzer reports one segment for a bare JPEG and three for a bare PNG, and why metadata removal touches a different part of each file.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

Both formats can carry metadata, so why does the same metadata operation behave so differently between a JPEG and a PNG?

This research compares container structure between JPEG and PNG using this repository's own four-image corpus. It does not claim that one format is more private than the other and does not recommend a format for any purpose.

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

JPEG: marker-delimited segments

A JPEG begins with a start-of-image marker and then a sequence of marker segments, each with a two-byte length. Metadata lives in APP segments, with APP1 for EXIF and comment markers for free text. Our analyzer walks the marker chain and names APP1 as EXIF, reporting two metadata segments for the fixture that carries EXIF and a comment.

PNG: length-prefixed named chunks

A PNG begins with an eight-byte signature and then a sequence of chunks, each with a four-byte length, a four-byte type, its data, and a four-byte checksum. Metadata lives in text chunks. Our analyzer reads each chunk's type and reports three metadata chunks for the text fixture.

The measured baseline difference

A minimal JPEG in our corpus reports one segment with zero metadata. A minimal PNG reports three segments, the header, image data, and end marker, also with zero metadata. The segment counts differ because the formats describe their own structure differently, not because one carries more information.

Why removal feels different

Removing a JPEG APP segment means cutting a contiguous marker block, which is a simple byte operation. Removing a PNG text chunk means removing a length-prefixed chunk and its checksum, then rewriting nothing else because chunks are independently addressed. Both are structural edits, and neither is the same as editing visible content.

What this means for a detection claim

Because the two containers are structurally different, one parser cannot naively handle both. Our analyzer dispatches on the file signature and applies the correct walk for each format, which is why it can report a JPEG EXIF tag directory and a PNG keyword list from the same tool.

Where the formats agree

In both formats, metadata is additive and does not affect rendering. That shared property is why a metadata removal can protect privacy without visibly changing an image, and it is the one conclusion that holds across both containers.

Why marker bytes exist in JPEG

The JPEG standard predates modern container conventions and identifies each segment by a single marker byte rather than by a named type. A reader must know the marker numbering to classify a segment, which is why our analyzer carries a marker table mapping 0xE1 to EXIF and 0xFE to a comment. Unknown markers are reported by their hex value rather than dropped, so an unfamiliar segment still appears in the output.

Why PNG names its chunks

PNG identifies each chunk by a four-character type code such as IHDR or tEXt, which makes classification self-describing. A reader does not need a table to know that a text chunk is text. The cost is that the type occupies four bytes per chunk rather than one, which is part of why a minimal PNG reports more segments than a minimal JPEG while carrying less information.

The checksum difference

Each PNG chunk carries a CRC over its type and data, so corruption is detectable per chunk. JPEG segments carry no per-segment checksum, and integrity is left to the transport or the application. For a metadata walk this means a PNG parser can verify that the chunk it classified is intact, while a JPEG parser cannot, which is a real difference in the strength of the classification even though both produce a segment list.

Why this affects removal confidence

Removing a PNG text chunk means removing a length-prefixed, checksummed unit, and leaving every other chunk valid because chunks are independently addressed. Removing a JPEG APP segment means cutting a marker block, after which the following markers still parse because the chain is offset by the segment lengths. Both operations are structurally safe when done correctly, and both are verifiable by re-running the analyzer and confirming the metadata count fell to zero.

Why the two formats diverged

JPEG was designed for photographic compression and its container grew by convention rather than by a single specification, so segments are identified by marker numbers that a reader must know. PNG was designed later with an explicit chunk model, so each unit names its own type and carries its own checksum. The two approaches reach the same goal, carrying structured data beside image data, by routes that look nothing alike to a parser.

How the parser dispatches

The analyzer reads the first bytes of a file and checks for the PNG signature or the JPEG start-of-image marker. It then applies the matching walk: marker-chain traversal for JPEG and chunk traversal for PNG. Dispatching on the signature is what allows one tool to report a JPEG EXIF tag directory and a PNG keyword list, and it is why the analyzer never needs the file extension or a content-type header to decide.

Why the baseline counts differ

A minimal JPEG reports one segment, because the image data is not wrapped in a named unit. A minimal PNG reports three, because the header, the compressed pixel data, and the end marker are each a named chunk. Neither file carries metadata, so the count difference reflects the formats' framing rather than their content, which is why the count alone must never be read as a metadata measure.

How removal is verified in each case

After a removal, re-running the analyzer should report a metadata segment count of zero for the JPEG and a metadata chunk count of zero for the PNG, with the image segments or chunks unchanged. That is a direct verification of the operation, independent of any claim the tool makes about what it removed, and it works the same way for both containers because it checks by walking rather than by trusting a report.

How marker numbering became conventional

The JPEG standard reserved a range of markers for application use and assigned no further meaning to most of them, so segments such as EXIF took the next available number by agreement among implementations. That is why a parser needs a table rather than a rule: the marker numbers are conventional rather than semantic. PNG avoided the problem by making the type self-describing from the start.

Why the checksum difference matters for verification

A PNG chunk carries a CRC over its type and data, so a parser can confirm that the unit it classified is intact before relying on it. JPEG segments carry no per-segment integrity value, so a parser must trust the transport or the application. For a metadata walk this means a PNG classification is checkable against corruption while a JPEG one is not, which is a real difference in the strength of the evidence even when both produce a segment list.

What the two-format comparison establishes

It establishes that a single tool can answer the same question about two structurally unrelated containers by reading each one's own framing. That is a stronger result than handling one format well, because it shows the method generalises from a principle, reading the structure, rather than from a per-format shortcut. The guide presents the mechanism and lets the reader see why the same procedure applies twice.

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 compared JPEG segment walking against PNG chunk walking on the same corpus, which is what shows how differently the two containers store the same kind of metadata.

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