Anatomy of a PNG File, Byte by Byte

PNG is one of the more pleasant binary formats to read by hand. It is built from self-describing chunks, every one is checksummed, and the format encodes information in a place most designs would not think to use — the capitalisation of its own field names. This page walks through the structure completely, with a real file in hex.

The signature

Every byte is doing a job, and the design is worth appreciating:

• 89 — has the high bit set. Software that strips the eighth bit, as some 7-bit transfer paths did, changes this byte and the corruption is immediately detectable.
• 50 4E 47 — PNG, readable in any hex dump or text editor.
• 0D 0A — a CRLF pair. A transfer that converts line endings to Unix style deletes the 0D.
• 1A — DOS end-of-file. Running TYPE image.png stops here rather than dumping binary across the terminal.
• 0A — a bare LF. A transfer converting to Windows line endings turns this into 0D 0A, again detectably.

The two line-ending bytes catch conversion in both directions. In 1995, transferring a binary file over FTP in ASCII mode was a common and silently destructive mistake, and these eight bytes turn it into an immediate, clear failure.

Chunk structure

Two design consequences follow from the length coming first. A decoder can always skip a chunk it does not recognise — read the length, jump that far, continue. And it can validate every chunk independently, so corruption is localised and identifiable rather than cascading.

The capitalisation rule

This is the cleverest thing in the format. A chunk type is four ASCII letters, and the case of each letter is a bit of machine-readable information.

The fourth bit is the subtle one and solves a real problem. Suppose an editor opens a PNG containing a chunk it has never heard of, modifies the image, and saves. Should it keep the unknown chunk?

It depends entirely on what that chunk describes. A copyright notice should survive. A chunk describing histogram data for the original pixels is now wrong and must be dropped. The editor cannot know which — but the chunk name tells it, without understanding the chunk at all.

Four bits of metadata carried in a field that had to exist anyway, at zero cost. It is the kind of design detail that separates formats which age well from formats which do not.

The four critical chunks

IHDR — the header

Always first, always exactly 13 bytes:

Types 1 and 5 do not exist — the numbering is a bit field where bit 0 means palette, bit 1 means colour, bit 2 means alpha, and the missing values are combinations that make no sense.

IDAT — the pixel data

All IDAT chunks concatenated form a single zlib stream. Decompress it and you get the raw scanlines — each one prefixed by a single byte naming the filter applied to that row.

The filters compress nothing themselves. They transform the data into a form that compresses well — a smooth gradient becomes a long run of the same small difference, and DEFLATE handles runs extremely efficiently.

The filter is chosen per row, so a good encoder tries all five on every scanline and keeps whichever produces the most compressible output. This is exactly what oxipng and zopflipng do more thoroughly than typical export code, which is why they shrink files by 10–30% without altering a single pixel.

PLTE and IEND

PLTE holds up to 256 RGB triples, three bytes each. Required for colour type 3, optional as a suggested quantisation for types 2 and 6, forbidden for greyscale types.

IEND is always the same twelve bytes and carries no data at all:

AE 42 60 82 at the end of a file is a reliable PNG marker. It is also useful for a specific recovery case: data appended after IEND is ignored by decoders, so files sometimes carry hidden payloads there.

Ancillary chunks worth knowing

How APNG stays compatible

APNG is a good illustration of the naming rules working. Its three chunks are all lowercase-initial, so they are ancillary — a decoder without APNG support skips them entirely and renders the IDAT as a normal still image.

So an animated PNG shown in software that has never heard of APNG displays the first frame correctly rather than failing. That graceful degradation was designed in, and it is why APNG could be deployed by browsers without breaking anything.

Reading a real file

Adam7 interlacing

Interlaced PNG stores the image in seven passes, each a sparse sampling of the whole picture, so a partially downloaded file shows a low-resolution version of the entire image rather than the top portion.

Pass 1 is one pixel in 64. Each subsequent pass fills in more. The technique is named after Adam Costello, who designed it.

It made real sense over a modem. Today it is usually a mistake: interlacing typically makes the file 20–35% larger, because splitting the image into seven sparse passes destroys the local coherence the prediction filters depend on. On a modern connection the progressive display buys nothing that matters and costs bandwidth on every load.

Summary

• The 8-byte signature is a corruption test for the transfer failures of its era.
• Chunks are length, type, data, CRC — self-describing, so unknown chunks are skippable.
• Capitalisation in chunk names carries four bits of meaning, including whether an editor may preserve a chunk it does not understand.
• IHDR, PLTE, IDAT, IEND are the critical chunks.
• Colour type 3 uses a quarter of the bytes for images with 256 or fewer colours.
• Filters run per scanline, which is why optimisers can shrink files without changing pixels.
• PNG does carry metadata in tEXt and iTXt chunks. Strip it before publishing.
• Interlacing costs 20–35% and buys little today.

Frequently Asked Questions