PNG Inspector: Chunk, CRC and Header Viewer

Pick the .png with the file chooser and the page immediately lists the IHDR header and every chunk in file order, each with its offset, length and CRC status. Further panels appear only when the file has the matching data: colour information, text chunks, APNG frames, eXIf location or bytes after IEND. The picture itself is not shown; this view is about how the file is built, so use any image viewer to look at the image.

No. The PNG is read through your browser's file access and parsed by script in this tab, and the inspection makes no network requests, not even for web addresses written inside text chunks. The bytes and any extracted text are not saved to localStorage, IndexedDB or cookies, so closing the tab discards them.

Yes. Any current browser on Windows, macOS, Android or iOS can run the inspector, so there is nothing to install on either a desktop or a phone. On a computer pick the file from Explorer or Finder; on a phone tap the file chooser and select from Photos or the Files app. Files close to the 50 MB limit may be slow on phones with little memory.

The notPng error means the first eight bytes are not the PNG signature 89 50 4E 47 0D 0A 1A 0A; on its own it cannot tell a renamed file of another format from a PNG whose opening bytes were damaged. The page shows the bytes it actually found. If they match a known signature, such as FF D8 FF for JPEG, 52 49 46 46 for RIFF files like WebP or 47 49 46 for GIF, the file is most likely that format, and only then is renaming it and opening it with a matching tool worthwhile. If the bytes match nothing recognisable, the start of the file is probably corrupted; renaming will not help, so get a fresh copy from the source.

A CRC mismatch means the bytes of that chunk no longer match the checksum written next to them, which typically comes from a damaged transfer or a careless edit. The row is highlighted in the chunk table while all later chunks are still parsed, so you can see exactly which part is affected. This page only reads files and cannot repair them; get a fresh copy or re-save the image in an editor.

Both indicate an incomplete file, most often a download or copy that stopped early. truncatedChunk reports the byte offset where the data ran out and how many chunks were read before it. If only the closing IEND chunk is absent, the status shows Partial and the chunks read so far are still listed, which tells you roughly how much is missing.

Up to 50,000,000 bytes (about 50 MB); a bigger file is rejected with fileTooLarge before any parsing starts, and the limit cannot be raised. Within that, up to 200,000 chunks are listed and the combined text preview is cut at 200,000 characters, with a warning when that happens.

No. A valid CRC only confirms that each chunk's bytes are intact; it says nothing about safety, origin or editing history. Every image editor recomputes CRCs when it saves, so a heavily altered image passes just as cleanly as an original. The inspector does not scan for malware, detect AI generation or judge authenticity.

It displays uncompressed text up to a shared 200,000-character preview limit and reports compressed text only by size. tEXt keyword and value are decoded as Latin-1; uncompressed iTXt is decoded as UTF-8 along with its language tag and translated keyword. If all text entries together exceed 200,000 characters, the display stops at that point and a truncation warning appears. For zTXt and compressed iTXt you see the keyword, compression method and compressed byte length, but the text is not decompressed. Values are displayed as plain characters, so HTML inside them never runs.

A file with an acTL chunk is an APNG, and the inspector then adds an animation panel and a frame table. You get the declared frame count and loop count, each frame's rectangle, delay fraction, dispose and blend operation, and a total duration in milliseconds summed from the frame delays, with a zero denominator counted as 100. A plain PNG has none of these chunks. Nothing is played or decoded to build the timeline.

No. It reports only whether an eXIf chunk exists, where it starts and how many bytes it holds. Camera model, capture time and GPS coordinates are not parsed here; the result points you to the image metadata viewer, which reads those fields.

Yes. Open this page, choose the file and the IHDR panel shows bit depth and colour type at once, free and without an account. Colour type 0 is greyscale, 2 is RGB, 3 is indexed colour, 4 is greyscale with alpha and 6 is RGBA. Combinations the PNG standard forbids, such as colour type 2 at bit depth 4, are flagged as they are instead of being corrected.