How a 67-Byte PNG Stores a Single Black Pixel

ZUSAMMENFASSUNG

In 30 Sekunden

Reading Evan Hahn’s article, Theo Browne breaks down a one-pixel, 67-byte PNG and explains what each part of the file does. He also explores color palettes, interlacing, compression overhead and why other tiny images can have the same file size.

1Fixed overheadSignature and required chunks account for most of this tiny file.
2IHDR describes the imageThe header records dimensions, color type, bit depth and other methods.
3Compression can add bytesFor two bytes of data, zlib overhead makes the payload larger.
4More pixels, same sizeAn eight-by-one black image can use the same space as the one-pixel example.

Das Wichtigste

PNG starts with a fixed signature followed by typed chunks.
Required chunk structure adds overhead even for a single pixel.
The image header records dimensions, color type, bit depth and encoding methods.
Filters prepare scanline bytes for compression and can use neighboring data.
Compression overhead can make very small payloads larger.

ThemenSoftware engineering

VOLLTEXT

Den bearbeiteten Text nach Kapiteln lesen

Transkript zeigen

Nur das Transkript

A 67-byte PNG

Theo Browne walks through Evan Hahn’s article about a 67-byte PNG containing one black pixel. The tiny example exposes the format’s required structure and the overhead that exists even when there is almost no image data.

The example has four pieces: an eight-byte signature, a 25-byte image header chunk, a 22-byte image-data chunk and a 12-byte end chunk. Together they total 67 bytes.

Signature and chunks

Every PNG starts with the same eight-byte signature. A decoder can check it before parsing the rest of the file; the signature includes the letters PNG and helps identify the format.

After the signature, the file is built from chunks. Each chunk has a length, a four-byte type, data and a four-byte CRC checksum; even a chunk with no data occupies 12 bytes.

The length describes only the data field, not the entire chunk. Required chunks appear in a defined order: the image header comes before image data and IEND marks the end.

Browne compares loading image data progressively with baseline and progressive JPEG. He later corrects himself: PNG also supports interlacing, which can reveal a coarse version before all detail arrives.

The image header

The IHDR chunk has 13 bytes of data. It records width, height, bit depth, color type, compression, filter and interlace methods; the chunk’s length, type and checksum add another 12 bytes.

For the example, the width and height are both one. Grayscale color type zero and one bit per sample are enough to represent a black pixel, avoiding the extra channels required by true color.

Bit depth controls how many values each sample can represent. A more expressive format can produce the same visible black pixel but may need more data to describe it.

Color and transparency

Browne explains indexed color: a palette stores available colors and pixels refer to entries by index. This can save space when an image uses a limited set of colors.

Transparency adds another representation concern, whether through an alpha channel or other supported transparency information. Browne notes that browser video workflows and still-image formats differ in their handling of transparency.

The example sets the PNG compression and filter methods to zero and does not use interlacing. The IHDR checksum covers the chunk type and data, allowing corruption to be detected.

Scanlines and compression

The IDAT chunk holds compressed image data. Before compression, image pixels are arranged in scanlines, each preceded by a byte identifying its filter.

The single-pixel example uses filter type zero, meaning no filtering. Browne corrects an earlier oversimplification: [PNG filters](https://www.w3.org/TR/PNG-Filters.html) can use neighboring bytes or a previous scanline to prepare data for compression.

The black pixel needs one bit, but its scanline is padded to a whole byte. Together with the filter byte, the uncompressed image data for this example is two zero bytes.

PNG wraps image data in zlib using DEFLATE. Compression usually saves space, but for two bytes the headers and checksums add overhead, making the encoded payload larger than its input.

The ten-byte zlib payload includes a header, a compressed block and an Adler-32 checksum. The surrounding IDAT chunk has its own CRC, serving a separate integrity check.

The end and other tiny images

The final IEND chunk has zero data bytes, but still needs length, type and CRC fields. That fixed twelve-byte ending completes this minimal example.

The one-pixel image is not the only image of this size. The article shows an eight-by-one black image that also fits in 67 bytes because it uses bits that would otherwise be padding in the pixel byte.

A one-pixel grayscale image with more shades can also tie at 67 bytes in the example. The lesson is that file overhead and compression behavior do not scale directly with the visible number of pixels.

Exploring real PNG files

Browne recaps the signature, required chunks and compressed data. He demonstrates the author’s chunk explorer on a larger PNG, revealing metadata and multiple image-data chunks.

He also points to an example that generates a single-color PNG programmatically. Understanding the format as structured bytes, rather than only as an export target, makes such tools easier to reason about.

The discussion closes with a note that decoders impose practical limits even when a format can represent very large images. Browne credits Hahn’s article and encourages readers to explore the format further.