How PNG Actually Stores Your Pixels

Fri, 14 Aug 2026 10:00:00 -0500

I’m starting a series on file formats. Not “here are the ten image formats you should know,” but the actual bytes: what’s in the file, in what order, and why someone decided it should be that way.

Starting with PNG, because it’s the format most developers touch every day and almost nobody has looked inside.

I am likely to cover a few things that other explainer documents have covered, such as chunk structure and chunk types. However, I’d like to dig into some details that are not often mentioned, such as where your pixels went.

A Format Born From a Patent Fight

PNG exists because of a licensing ambush. On 28 December 1994, right in the middle of the holidays, Unisys announced an agreement to start collecting royalties from authors of GIF-supporting software, on the strength of its patent on the LZW compression algorithm that GIF used.

The response was fast. A draft for a replacement format was posted to comp.graphics on 4 January 1995, one week later. It was originally called PBF, for Portable Bitmap Format, and got renamed to PNG two days after that. The format shipped as a W3C Recommendation in October 1996.

Two things about that origin still show in the bytes. The format is aggressively defensive, because it was designed by people who expected files to be mangled in transit. And it is aggressively extensible, because they had just watched a format become unusable for reasons that had nothing to do with its technical design.

Eight Bytes of Paranoia

Every PNG starts with the same eight bytes:

Hexadecimal:  89  50  4E  47  0D  0A  1A  0A
ASCII/Ctrl: \x89  P   N   G  \r  \n \x1A \n

P N G in the middle is obvious. The other five bytes are a booby trap for 1995-era file transfer, and each one catches a specific failure:

0x89 has the high bit set. Some 7-bit transfer paths stripped bit 7 from every byte. If that happened, this byte arrives as 0x09 and the file is detectably wrong on byte one.
0x0D 0x0A is a DOS line ending. A text-mode FTP transfer that “helpfully” converts CRLF to LF mangles it.
0x1A is Ctrl-Z, the MS-DOS end-of-file marker. If you TYPE a PNG at a DOS prompt, output stops here instead of spraying binary at your terminal and leaving it in a weird state.
0x0A is a bare LF, catching the opposite conversion: LF silently expanded to CRLF.

Who would have thought that so many bits were used just to account for line endings in different operating systems? I suppose it’s good to plan ahead when designing a file format.

Everything Is a Chunk

After the signature, a PNG is a flat sequence of chunks. No central directory, no offset table. You read them in order.

Every chunk has the same four-field shape:

Field	Size	Notes
Length	4 bytes	Big-endian, counts only the data field
Chunk Type	4 bytes	Four ASCII letters
Chunk Data	Length bytes	Can be zero-length
CRC-32	4 bytes	Computed over type and data, not over length

Two details worth keeping. The length field is 32 bits but the spec caps values at 2³¹−1, so the high bit is always clear. And the CRC covers the type plus the data but skips the length, which means a corrupted length field is not detected by the chunk’s own checksum.

The chunk type is where PNG does something clever. Those four letters are ASCII, and bit 5 of an ASCII letter is what distinguishes uppercase from lowercase (A is 0x41, a is 0x61). PNG uses that bit in each of the four positions as a flag:

Position	Uppercase means	Lowercase means
1st	Critical: decoder must understand it	Ancillary: safe to ignore
2nd	Public, registered in the spec	Private, vendor-specific
3rd	Reserved, must be uppercase today	(reserved for future use)
4th	Unsafe to copy if pixels changed	Safe to copy blindly

So a decoder that has never heard of tEXt can tell from the lowercase t that skipping it is fine. A decoder hitting IDAT sees the uppercase I and knows it cannot skip it. The capability negotiation is encoded in the name itself, which means you can add chunk types decades later without breaking old readers. This is why APNG could bolt animation onto PNG without a version bump.

Four chunk types are critical: IHDR (header, always first), PLTE (palette), IDAT (the pixels), and IEND (a zero-length terminator).

IHDR Is the Decode Key

IHDR is exactly 13 bytes and it comes first because nothing else can be interpreted without it:

Width (4 bytes) and Height (4 bytes), big-endian
Bit depth (1 byte): bits per sample, one of 1, 2, 4, 8, 16
Color type (1 byte): what a pixel is made of
Compression method (1 byte): always 0
Filter method (1 byte): always 0
Interlace method (1 byte): 0 for none, 1 for Adam7

Bit depth and color type together determine everything about the pixel layout, and only certain combinations are legal:

Color type	Name	Samples per pixel	Legal bit depths
0	Greyscale	1	1, 2, 4, 8, 16
2	Truecolor (RGB)	3	8, 16
3	Indexed	1 (a palette index)	1, 2, 4, 8
4	Greyscale + alpha	2	8, 16
6	Truecolor + alpha (RGBA)	4	8, 16

Note the gaps. You cannot have 16-bit indexed color, because a palette holds at most 256 entries and 8 bits already addresses all of them. You cannot have 1-bit RGB, because a “1-bit red sample” isn’t a useful thing. The table isn’t arbitrary; each missing cell is a combination that would be incoherent.

Also note that bit depth is per sample, not per pixel. A bit depth of 16 with color type 6 means 16 bits each for R, G, B, and A: 64 bits per pixel. That’s the “64-bit RGBA” you see in PNG marketing.

Where the Pixels Actually Live

Uncompress all the IDAT data and concatenate it, and you get a byte stream. That stream is not a grid. It’s a sequence of scanlines, one per image row, top to bottom. And each scanline is:

[1 filter type byte][packed sample data for the whole row]

That leading byte is not pixel data. It’s a number from 0 to 4 saying which filter was applied to this row.

The sample data is packed with no padding between pixels and no separators. Samples appear in a fixed order within each pixel:

Greyscale: grey
Truecolor: red, green, blue
Indexed: palette index
Greyscale + alpha: grey, alpha
Truecolor + alpha: red, green, blue, alpha

Here is an example PNG, filter type 0 (no filtering) on both rows:

scanline 0: 00 ff 00 00 00 ff 00 00 00 ff ff ff 00
            ^^ filter byte
            ^^^^^^^^ red pixel (ff,00,00)
                     ^^^^^^^^ green pixel (00,ff,00)

scanline 1: 00 00 00 00 80 80 80 ff ff ff ff 00 ff
            ^^ filter byte
               ^^^^^^^^ black    ^^^^^^^^ white

Twelve bytes of pixel data per row (4 pixels × 3 samples), each prefixed by one filter byte, for 26 bytes of raw stream. The complete file, signature and all four chunks included, is 83 bytes.

The whole model at 8-bit depth: walk the row, emit samples in order, move on. No alignment, no padding, no per-pixel headers.

Bit depths of 1, 2, and 4 only apply to greyscale and indexed images. Multiple pixels get packed into a single byte.

These samples are packed into bytes with the leftmost sample in the high-order bits of a byte followed by the other samples for the scanline.

Leftmost pixel goes in the high bits. So for a 12-pixel-wide 1-bit greyscale image:

pixels       : 1 1 0 1 0 0 0 1  1 0 1 1
packed bytes : 0xd1 0xb0
               11010001 10110000
                              ^^^^ unused

Twelve pixels need 12 bits, which rounds up to 2 bytes, leaving 4 bits spare at the end. The spec’s language on those leftover bits:

When there are multiple pixels per byte, some low-order bits of the last byte of a scanline may go unused. The contents of these unused bits are not specified.

Scanlines always start on a byte boundary. Row 2 never continues in the leftover bits of row 1’s last byte.

At bit depth 16, each sample is two bytes, most significant byte first. The spec calls it network byte order. On x86 and ARM, which are little-endian, that means every 16-bit sample needs a byte swap on read and on write.

The Filter Byte Is the Whole Trick

Now back to that leading byte on every scanline.

PNG uses DEFLATE, the same algorithm as gzip and zip. If you just DEFLATE’d raw pixels, PNG would compress about as well as gzipping a bitmap, which is to say barely at all. Photographs and gradients don’t repeat exact byte sequences, and LZ77 needs exact repeats.

So before compressing, PNG transforms each scanline into differences from its neighbors. Five filters are available, chosen per scanline:

Type	Name	Transform
0	None	store the byte as-is
1	Sub	subtract the byte from the pixel to the left
2	Up	subtract the byte from the pixel above
3	Average	subtract the average of left and above
4	Paeth	subtract whichever of left/above/upper-left is the best predictor

All arithmetic is mod 256, which is what makes it reversible without storing a sign. And “the pixel to the left” means the byte at the same position in the previous pixel, so for RGB the red sample is compared against the previous red sample, not against the previous blue.

Take a 16-pixel greyscale gradient stepping by 10:

raw scanline     : 00 0a 14 1e 28 32 3c 46 50 5a 64 6e 78 82 8c 96
after Sub filter : 00 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a

Sixteen distinct byte values become two. The image is unchanged and the transform is exactly reversible, but LZ77 now sees a run it can encode in almost nothing. On this toy row, DEFLATE produces 28 bytes for the raw version and 15 for the filtered one.

Sixteen bytes is far too small for DEFLATE to stretch its legs, so don’t read that ratio as typical. The point is the entropy collapse: filtering doesn’t compress anything, it rearranges the data so the compressor has something to find.

That per-scanline choice is also why two encoders produce different-sized files from identical pixels. libpng, ImageMagick, oxipng, and zopflipng all ship different filter-selection heuristics. Same spec, same decoded output, different bytes on disk. Most PNG optimizers are search algorithms over filter choices, not better compressors.

The Compression Pipeline, End to End

Putting it together:

raw pixels
  -> pack into scanlines (samples in order, sub-byte packing if needed)
  -> prepend a filter byte per scanline, apply the filter
  -> DEFLATE the whole concatenated stream (LZ77 + Huffman)
  -> wrap in a zlib container (RFC 1950)
  -> split across one or more IDAT chunks

A few consequences fall out of that ordering:

The zlib stream spans chunks. IDAT boundaries are arbitrary. A decoder must concatenate every IDAT payload and then decompress; decompressing them individually fails. Encoders split them for streaming, not for structure.

The Adler-32 checksum in the zlib wrapper covers filtered bytes, not your original pixels. It validates decompression, not image fidelity. The per-chunk CRC-32 is what protects against transmission corruption.

Compression is global across the image. LZ77’s 32KB sliding window means row 400 can match against row 380 if they’re similar. This is why a 64×64 solid color block compresses to 136 bytes while a 64×64 gradient of the same dimensions takes 10,362 bytes, against 12,288 bytes raw. Uniformity compresses; novelty doesn’t.

And a practical one: for that solid-color block, encoding as indexed color with a one-entry palette produces a 99-byte file instead of 136, because each pixel is one index byte instead of three samples. If your image has few colors, color type 3 usually beats truecolor even after DEFLATE gets its turn.

Interlacing, Briefly

If the interlace byte in IHDR is 1, the image uses Adam7: the pixels are transmitted in seven passes over an 8×8 grid, coarse to fine, so a partially-downloaded image renders as a low-resolution preview that sharpens.

Two things to know. Each pass is filtered and encoded as an independent sub-image with its own scanlines and filter bytes, so a decoder can’t treat the stream as one grid. And Adam7 typically makes files larger, because breaking the image into seven sparse sub-images destroys exactly the local coherence that filtering and LZ77 depend on. It was a good trade on a 28.8k modem. On any modern connection it costs size and complexity for a progressive render nobody waits around to see.

What This Buys You

The design decisions hold up well for a 1996 format:

Unknown chunks are safe by construction, so the format extended to EXIF metadata, ICC profiles, and animation without ever breaking old decoders.
Every chunk is individually checksummed, so corruption is localized and detectable rather than silently rendering garbage.
Filtering is a preprocessing step, not a compression format, which means encoders can get better forever without touching the spec. A file written by zopflipng today decodes fine in a 1997 reader.

That extensibility is not just historical. PNG got a Third Edition as a W3C Recommendation on 24 June 2025, which finally standardized APNG, added an eXIf chunk for camera metadata, and brought in HDR through three new chunks (cICP, mDCV, cLLI). Thirty years on, the container still had room.

Where it shows its age is DEFLATE, which is a 1990s compressor. Lossless WebP does beat it: Google’s own study puts WebP lossless at 23% smaller than PNGs already optimized with ZopfliPNG, and 42% smaller than default libpng output. Worth noting the baseline matters enormously there, and Google’s WebP FAQ quotes a different figure (26%) than the study it links to.

Lossless AVIF is a murkier story than the marketing suggests. AOMedia publishes no general lossless-AVIF-versus-PNG number at all; its quantified claims (50% versus JPEG, 30% versus WebP) are all about lossy encoding. The only primary figure available is 10% versus a 16-bit PNG for a single demo image using a new v1.2.0 feature. Independent testing regularly finds lossless AVIF producing larger files than PNG for flat synthetic images like icons, UI, and charts. If you’re picking a format for screenshots and diagrams, test on your own images rather than trusting a general ranking.

Next in the series: the opposite of all this. A text file, which announces nothing about itself at all.

Sources

W3C PNG Specification, Third Edition — the current standard; §7.2 covers scanlines and sample packing, §9 covers filtering
RFC 2083 — the original 1997 IETF PNG specification
RFC 1950 (zlib) and RFC 1951 (DEFLATE) — the compression layer
libpng PNG history — the Unisys announcement, the PBF name, and the January 1995 timeline
WebP Lossless and Alpha Study — Google’s 23%/42% lossless figures and their baselines
AOMedia on AVIF v1.2.0 — the 10% lossless figure, and its narrow scope

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

Png on LLBBL Blog