Image privacy research

How Much of an Image File Is Actually Metadata

Metadata is often described as a small extra attached to an image. In one of our generated JPEGs it is four fifths of the file. The reason is container design rather than file size: JPEG stores metadata as standalone APP segments that sit before the compressed image data, and on a tiny image those segments dominate. We measured both formats to show how far the share can move.

By BeanNest Studio Reviewed September 20, 2026

What this guide helps you decide

A photo carries metadata alongside its pixels. How much of the file is that metadata, and does the answer depend on the format?

This research measures metadata segment share in this repository's own four-image corpus. It does not claim a typical share for camera photos and does not describe any specific editor's metadata handling.

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

The two container models

JPEG places metadata in APP segments that precede the compressed image scan. PNG places metadata in named chunks interleaved with image data, and a PNG without extra chunks carries only IHDR, IDAT, and IEND. Our analyzer classifies each segment or chunk as metadata or image data and totals both.

The measured shares

Our JPEG with EXIF and a comment is 166 bytes, of which 133 bytes across two segments are metadata, a share of 80.1 percent. Our JPEG without them is 33 bytes with zero metadata segments. Our PNG with three text chunks is 7051 bytes with 117 metadata bytes, a share of 1.7 percent. Our PNG without them has zero metadata segments.

Why the JPEG share is so high

The pixel payload in our baseline JPEG is deliberately minimal, so the fixed-size EXIF block is almost the entire file. This does not mean a real camera photo is 80 percent metadata; a multi-megabyte photo would share the same EXIF block across far more pixel data. It means that on small images the metadata is not a rounding error, and a naive size expectation will be wrong.

Why the PNG share is low

Our PNG carries a compressed pixel payload of several kilobytes, so 117 bytes of text chunks are a small fraction. PNG text chunks are also stored as plain key and value pairs without a binary directory structure, so they are compact relative to their information content.

What the analyzer actually detects

For PNG it reads chunk lengths and types and identifies tEXt, zTXt, and iTXt as text metadata, reporting the keyword for each. For JPEG it walks the segment markers, names APP1 as EXIF, and separately parses the EXIF tag directory. The reported keyword list for our PNG, Author, Software, and Comment, is produced by parsing rather than by pattern matching.

Reading a metadata claim critically

A credible metadata claim names the file it measured. A percentage without an input file cannot be checked, because the share depends on both the metadata block and the pixel payload. Our own numbers are stated with the exact corpus files that produced them, which is the standard these guides hold to.

Walking the JPEG marker chain

A JPEG begins with a start-of-image marker and then a sequence of segments, each introduced by a marker byte and carrying a two-byte length. Our analyzer walks that chain from offset two, reads each length, and classifies the segment by its marker: 0xE0 as JFIF, 0xE1 as EXIF, 0xE2 as ICC, 0xED as IPTC, 0xEE as Adobe, and 0xFE as a plain comment. Metadata is the range from 0xE0 to 0xEF plus the comment marker. Everything else, including the frame header and the scan data, is image content. On the fixture that carries EXIF and a comment, that walk reports two metadata segments totalling 133 bytes.

Walking the PNG chunk sequence

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 CRC. The analyzer reads lengths and types until the end marker. It classifies IHDR, PLTE, IDAT, IEND, and tRNS as image chunks and everything else as metadata, which places the three text chunks in the second file into the metadata total. The reported counts are three segments for the clean file and six for the text file, matching exactly how the generator built them.

Why the same method serves both formats

The two walks differ in mechanics but share a purpose: read the container's own framing so the classification comes from the file rather than from a guess. A filename extension would not distinguish a PNG that carries text chunks from one that does not, and neither would a file size. Only walking the structure answers the question the guides ask, which is how much of this specific file is metadata.

What the analyzer does not count

It does not count colour profile data inside an ICC segment's payload as separate metadata beyond the segment itself, and it does not parse XMP packets that may sit inside an APP1 segment alongside EXIF. Both would require deeper parsing than the segment walk performs. The reported share is therefore a lower bound for files that carry those structures, and the guides state the share as a measured value for the corpus rather than as a ceiling for all images.

Why a segment count is stronger than a size estimate

A size estimate answers how large the metadata is but not whether it exists. A segment count answers both. When the analyzer reports zero metadata segments for the clean files and three for the text fixture, that is a statement about presence as well as quantity, and it can be checked by walking the same structure independently. A size figure alone could be produced by a rough heuristic; a count produced by walking the container cannot.

How the two fixtures were chosen

The clean files establish a baseline with no metadata at all, so the difference in the other pair is attributable entirely to the added segments. The text fixture adds three named chunks with realistic authoring keywords rather than random bytes, so the recovered keyword list can be read and understood. Choosing realistic keys makes the evidence interpretable; choosing random ones would have made the byte totals identical while leaving nothing to inspect.

Why the JPEG comparison is the more dramatic one

The JPEG pair shows a metadata share of zero percent and eighty point one percent while the PNG pair shows zero percent and one point seven percent. The difference comes from the pixel payload: the baseline JPEG in the corpus is deliberately minimal so the fixed EXIF block dominates, while the PNG carries several kilobytes of compressed pixels that dwarf its text chunks. The two pairs together show that format design and content size both matter.

What would change the measured share

Increasing the image dimensions would lower both metadata shares, because the pixel payload grows and the metadata block does not. Adding more metadata, such as a thumbnail or a full XMP packet, would raise them. The share is therefore a two-variable quantity, and any published figure must name the file it came from, because a share quoted without its input describes nothing.

How a reader can reproduce the measurement

The generator creates the four files deterministically, and the analyzer reports segment counts, byte totals, shares, and hashes. Running the two commands regenerates the same files with the same hashes and the same shares, which means the published numbers can be reproduced exactly rather than approximately. That reproducibility is what separates this corpus from a set of illustrative screenshots.

What the clean fixtures establish

A baseline with no metadata is what makes the other pair's result attributable. The clean PNG reports three segments and zero metadata bytes; the clean JPEG reports one segment and zero metadata bytes. Those counts match exactly how the generator wrote them, so they validate the walk as well as establishing the baseline. Without a zero case, a nonzero result could not be distinguished from a parser that counts every segment as metadata.

How a reader would apply this to their own file

Running the analyzer on any PNG or JPEG produces the same four fields: segment count, metadata segment count, metadata bytes, and share. Those answer whether the file carries metadata and how much. The tool needs no configuration and no network, so the check is available on any file a reader has, which is the practical value of publishing the method rather than only the corpus numbers.

Why the share must always be published with its file

The share depends on both the metadata block and the pixel payload, so a figure quoted without its input describes nothing. The corpus demonstrates the range, from eighty point one percent on a tiny JPEG to one point seven percent on a larger PNG, and neither value would predict the other. Any guide that published a share without naming the file would be inviting a generalisation the evidence does not support.

What the analyzer cannot tell about metadata provenance

It reports which segments and chunks exist, not where they came from or whether they were added deliberately. A text chunk could have been written by a camera, an editor, or a script. Provenance would require comparing against the original capture, which the corpus does not do. The guide therefore describes presence and size, and it does not speculate about origin.

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 totalled metadata segment bytes against total file bytes for all four corpus images, which separates the metadata share of a small fixture from the metadata share of a larger one.

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