IntactFile

Inspect a PNG file — chunk by chunk, with every CRC checked

When an image won't display, the damage is somewhere specific. This inspector reads the signature, the IHDR geometry, and walks every chunk verifying its CRC — locally, in your browser — so it can point at exactly where.

Your file never leaves your device — inspection runs in your browser. 0 bytes uploaded.

Drop a PNG file hereTap to choose a PNG file

Reads the 8-byte signature, the IHDR geometry, and verifies the CRC of every chunk.

100% in your browser. 0 bytes uploaded — open DevTools → Network and watch. Your file is read, never sent.

In short

This is a read-only inspector for PNG images. Drop a file and it checks the 8-byte signature (including the FTP newline-mangling that quietly breaks PNGs), reads the IHDR header for the dimensions and colour type, and walks the chunk stream verifying the CRC-32 on every chunk. You get a verdict, the image geometry, and a per-chunk table showing which chunks are sound and which are damaged or truncated. Nothing is uploaded and nothing is rewritten.

What the inspector reads

Every PNG begins with the same 8-byte signature, then a sequence of chunks: IHDR declares the width, height, bit depth and colour type; one or more IDATchunks hold the compressed pixels; IEND closes the file; and optional chunks carry metadata. Each chunk stores its length, type and data followed by a CRC-32 of that data — a built-in integrity check the inspector puts to use.

The scan verifies the signature (and detects the CR/LF mangling an FTP transfer in ASCII mode causes), parses IHDR and reports the geometry, then streams through every chunk recomputing its CRC. The per-chunk table lists each chunk's type, offset, length and CRC result; a chunk whose stored CRC no longer matches its data is flagged, and so is one cut short by truncation. That turns "the image is broken" into "theIDAT chunk at offset N is truncated" — a diagnosis you can act on.

Reading the verdict

Structurally valid

The signature is correct, IHDR is present and sane, and every chunk passes its CRC. If a viewer still won't show it, suspect that viewer rather than the file.

Damaged

The report names the class — signature damage, a missing IHDR, a bad CRC, a truncated file. A mangled signature or a small bad chunk is often repairable; damage inside the compressed pixel stream is not always, and the report is honest about which you have. Therepair tools start from this diagnosis.

Why "no upload" is verifiable, not a slogan

The image is read with the browser's own file APIs and every chunk is CRC-checked on your machine; the page makes no request that carries your data. You can prove it — open DevTools, select the Network tab, drop the file, and watch nothing leave. It's the same principle behind thezero-upload proof page, applied to inspection.

FAQ

Why won't my PNG display?

Common structural causes: the 8-byte signature was damaged (often by an FTP transfer in ASCII mode, which mangles the newline bytes); the IHDR header that declares the image's size is missing; a chunk's CRC no longer matches its data because a byte was flipped; or the file was truncated so the IDAT image data or the IEND marker never arrived. The inspector checks each and names the one that applies.

Does the file get uploaded?

No. The image is read in your browser and every chunk is verified there — 0 bytes are sent anywhere. Open DevTools, switch to the Network tab, drop the file, and watch that nothing carries it.

What is a PNG chunk, and what does the CRC tell me?

A PNG is a fixed signature followed by a sequence of chunks — IHDR (dimensions and colour type), IDAT (the compressed pixels), IEND (the end marker), plus optional metadata. Each chunk ends with a CRC-32 of its own data. The inspector recomputes every CRC; a chunk marked BAD has been altered since it was written, pinpointing exactly where the corruption is.

What does 'newline mangled' mean?

PNG's signature deliberately includes CR and LF bytes to detect transfers that 'helpfully' convert line endings. When a file is moved over FTP in ASCII mode, those bytes get rewritten and the signature — and often data throughout the file — is corrupted. The inspector flags this specific pattern because it has a specific cause and fix.

It says a chunk has a bad CRC — can it be fixed?

Inspection only reports; it doesn't change the file. A damaged signature or a bad CRC in a small chunk is often repairable; corruption inside the compressed IDAT stream is much harder because the pixel data carries no redundancy. The inspector is explicit about which case you're looking at so the expectation is honest.

Other inspectors: ZIP ·PDF · or, if the file is damaged,all repair tools