PNG Chunk Structure: IHDR, IDAT, IEND and Metadata

The eight signature bytes identify a PNG datastream. IHDR must follow immediately and declare width, height, bit depth, color type, compression, filtering and interlace. Image pixels then live in one logical compressed stream split across one or more IDAT chunks, and IEND closes the datastream.

Ancillary does not mean useless. iCCP and sRGB guide color, pHYs stores density or aspect information, eXIf can carry camera and GPS metadata, text chunks can expose names or software, and caBX can carry a C2PA manifest store. Their relevance depends on the user's task.

Every PNG chunk begins with a four-byte unsigned payload length and a four-letter type. The payload follows, then a four-byte CRC covers the type and payload but not the length field. The inspector reports both payload and complete chunk size so offsets remain understandable.

Length validation comes before CRC work. A declared payload that runs past the selected file is unsafe to read, so inspection stops at that boundary and reports the offset instead of attempting recovery from arbitrary later bytes.

A matching CRC is strong evidence that the chunk type and payload were not accidentally altered after the checksum was written. It is valuable for detecting damaged transfers, incomplete edits and simple byte corruption.

CRC is not a digital signature and has no trusted identity. An editor can rewrite a chunk and calculate a new matching CRC, so a fully green PNG map does not prove camera origin, authorship, chronology or an untouched visual scene.

IHDR's 13 bytes contain the canvas dimensions, sample bit depth, color type and method numbers used by the datastream. Impossible zero dimensions, an unexpected payload length or a second IHDR are structural failures rather than unusual creative choices.

The header can explain decoding limits but not the visible content. A 6000 × 4000 truecolor PNG may be a screenshot, rendered artwork, converted photograph or synthetic fixture; dimensions and color type do not determine its source workflow.

tEXt, zTXt and iTXt can contain descriptions, software names, comments or XMP packets. eXIf carries an EXIF profile. These blocks may expose personal or workflow context, but each needs field-level interpretation rather than automatic deletion.

iCCP, sRGB, cHRM and gAMA influence color interpretation. Removing them as if all metadata were private can change display behavior. A privacy decision should distinguish identifying text and location from color information needed for consistent rendering.

A conforming datastream places IHDR first, palette information before image data when required, one or more IDAT chunks in sequence and IEND last. Bytes after IEND are outside the PNG datastream even if a tolerant viewer ignores them.

Trailing bytes are a review signal, not automatic proof of malware or deception. They can come from a broken concatenation, an exporter defect, intentional application data or manual tampering. Preserve the input and compare a clean re-export rather than deleting evidence in place.

Save the original, export the JSON structure report and note the first error offset. Try opening a duplicate in a trusted image application and create a new PNG without overwriting the source. Inspect the new file again and compare dimensions, color and visible pixels.

If the image matters as evidence, do not treat a successful re-export as restoration of provenance. The derivative may be visually useful but has a new byte history. Keep hashes and chain-of-custody notes with the original while using the repaired copy only for viewing or delivery.