Every PNG begins with a damage test

Sep 16, 2026

Open any PNG in a hex viewer. The first eight bytes never change:

xxd -l 8 image.png

00000000: 8950 4e47 0d0a 1a0a                      .PNG....

In decimal that is 137 80 78 71 13 10 26 10. Only three of those bytes spell anything. The other five are there to break.

A checklist disguised as a header

PNG was designed in the mid-1990s, when an image usually reached you over FTP, and FTP had a text mode that rewrote whatever passed through it: newlines translated, the eighth bit stripped. So the signature was built as a row of traps, and the format's own rationale names each one.

• 137 — deliberately not ASCII. It "catches bad file transfers that clear bit 7", and keeps a text file from being mistaken for an image.
• 80 78 71 — PNG. The only part that is a name.
• 13 10 — carriage return, line feed. "The CR-LF sequence catches bad file transfers that alter newline sequences."
• 26 — control-Z, which "stops file display under MS-DOS", so a binary file would not spray across a terminal.
• 10 — one more line feed, which "checks for the inverse of the CR-LF translation problem".

A decoder can then read eight more bytes and confirm an IHDR chunk header of the right length, which "will catch bad transfers that drop or alter null (zero) bytes". All of it settled before a single pixel is decoded.

A small note

Nearly every failure on that list is extinct. FTP in ASCII mode, links that clear the eighth bit, TYPE on MS-DOS — none of that is how an image reaches you now. The checks still run, on every PNG your browser opens.

What the eight bytes leave out has aged better. From the same rationale: "there is no version number in the signature, nor indeed anywhere in the file. This is intentional." In June 2025, the third edition gave PNG animation and HDR colour. Thirty years on, there is still no version number to bump.