Validate a PNG File

signature · chunk order · every CRC · header legality · trailing bytes

A file won't open, or opens in one program and fails in another. This runs the structural checks the PNG specification defines and reports each one individually, so you get a specific answer — "the CRC on the third IDAT is wrong" — rather than "invalid image".

What gets checked

The 8-byte signature. That IHDR comes first and is exactly 13 bytes, and that IEND comes last and is empty. That at least one IDAT exists and that the IDATs are contiguous — the specification requires no other chunk between them, and this is a real bug in some hand-rolled writers. Every chunk's CRC-32, recomputed from the bytes rather than trusted.

From the header: that the dimensions are non-zero, and that the bit depth is legal for the colour type — indexed colour permits 1, 2, 4 and 8 bits but not 16; truecolour permits only 8 and 16. That compression and filter method are both 0, the only values the format defines. That a palette is present when the colour type is indexed and absent when it's greyscale. That PLTE and tRNS appear before the image data. And that nothing is appended after IEND.

What a failure usually means

Bad signature — the file isn't a PNG at all. Very often it's a JPG or WebP that was renamed, which most viewers handle by sniffing the content, so it "works" everywhere except the one strict tool that rejected it.

Bad CRC or truncated chunk — real damage. An interrupted download, a failed disk, a script that wrote the file without flushing. Truncation is the common one: everything up to a point is fine and then the file simply stops.

Illegal depth or type combination — written by software that got it wrong. Some decoders are permissive and display it anyway, which is why the file may look fine to you and be rejected by a stricter pipeline.

Trailing data after IEND — usually harmless, occasionally deliberate. Data hidden after IEND is a known way to smuggle payloads inside an apparently valid image.

Note the limit of this check: it validates the container, not the compressed stream. A file can pass every test here and still fail to render if the zlib data inside IDAT is corrupt in a way that preserves the chunk CRC. If everything passes and the image still won't open, the damage is inside the compressed pixels — try re-encoding it through JPG / WebP to PNG, which will save whatever the browser's decoder can recover.

FAQ