The Bytes Your Screenshot Kept

CRC-32 is unkeyed. Anyone who can change data can recompute the four stored CRC bytes, exactly as the laboratory does. RFC 3961 section 6.1.3 states the security boundary plainly for CRC-32: it is neither keyed nor collision-proof. That RFC uses different Kerberos conditioning, so it is cited only for the boundary, never for PNG computation.

The obvious repair is the wrong one. Swapping CRC-32 for a cryptographic hash stored in the same file changes nothing, because the editor recomputes that too. The SHA-256 above is printed as a local identity aid for exactly this reason: it tells you whether two byte sequences on your own machine are the same, and nothing about where either came from. What a checksum inside a file lacks is not strength, it is a key or a reference held somewhere the editor cannot reach. Authentication needs a keyed construction, a signature, or a digest recorded outside the file.

One more boundary, from the specification itself. Clause 13.1 says a decoder should check the CRC, and the decoder conformance conditions in clause 15.3.3 do not require it. Clause 13.2 explicitly contemplates decoders that do not check CRCs at all. So a red row here does not predict that any particular program will complain, and a green sweep is not a claim that a file is a valid PNG: the structural walk beside it is a separate check, and it is the one that refuses.

A CRC-32 is linear: the difference it reports between a file and a corrupted copy depends only on which bits changed, never on what the file said. That is why the reach of the check can be computed exactly rather than sampled. Collect the 32-bit signature of every single-bit change, then ask whether any combination of changes confined to a run of W bit positions cancels to nothing. For W up to 32 none does, so every burst that short is caught, including every one-bit and two-bit change. At W = 33 one does, and the page prints it: a pattern flipping 15 bits across 5 bytes. Applied to any chunk's covered bytes it leaves the stored CRC correct with no repair whatsoever. Read least-significant bit first it is exactly the generator polynomial, which is the reason it is invisible.

So "a CRC-32 detects accidental corruption" is a bounded claim, and the bound is worth saying out loud. It is not a claim about deliberate corruption at all, which is the point of the repair control above. PNG Third Edition clause 13.3 phrases the true version carefully: the CRC provides a robust defence against accidentally corrupted data.

Four rules here were written first and revised on 9 August 2026 after an adversarial review and an independent re-derivation produced specimens the original rules got wrong. They are listed because a rule changed after seeing data is a different kind of claim from one fixed in advance.

1. Color priority now runs over eligible chunks, not merely present ones. The first version picked the lowest priority number among the color chunk types it found. A reviewer supplied a three-byte cICP, which cannot be a valid cICP, and a well-formed cICP placed after IDAT, which Table 8 forbids. Both were reported as effective and a valid sRGB was reported as ignored. A color chunk now takes part only if it parses as its own type, sits before PLTE and IDAT, is the first of its type, and passes its own CRC. Chunks that fail any of those are shown as present and ineligible, with the reason.
2. The mutation check now requires a transition in the selected chunk. The first version passed whenever the mutated file had any failing CRC anywhere. That stayed green on a file that already contained a failure, and it would also have stayed green for a checksum implementation broken badly enough to fail everything. It now asserts separately that the selected chunk passed before the change and that the same chunk failed after it.
3. The color-removed pixel comparison is now withheld when it cannot say anything. The first version always decoded a third Blob with the color chunks removed and printed the pixel difference. For a file with no color chunk, which is the ordinary screenshot, removing color chunks returns the original bytes, so that comparison decoded the same file twice and printed a zero that was true by construction. It sat beside a real measurement in the same row of statistics and was indistinguishable from one. The page now checks whether the stripped variant differs at all and refuses the comparison when it does not.
4. The word "internally consistent" was narrowed to "CRC-consistent". An independent re-derivation of this subject, working from the specification without seeing this page, changed one byte of an IDAT zlib stream, recomputed that chunk's CRC, and found the file rejected by three separate decoders because of the Adler-32 inside the compressed data. The claim was true for tEXt and false as stated for every chunk carrying a zlib datastream. The page now computes that inner checksum and shows it disagreeing.

The parser checks all eight signature bytes, a complete header before reading a length, the 2³¹-1 PNG length limit, the computed end against the real file size, four alphabetic type bytes, IHDR first with exactly 13 bytes, defined IHDR values, palette order, consecutive IDAT chunks, at least one IDAT, and an empty IEND at the exact end. It stops at the first impossible boundary and reports the exact byte. A bad CRC does not desynchronize the walk, so it remains visible as a red result.

1. Portable Network Graphics (PNG) Specification (Third Edition), Portable Network Graphics Working Group, editors Chris Blume, Pierre-Anthony Lemieux, Chris Lilley, Chris Needham, Leonard Rosenthol, Chris Arley Seeger, Simon Thompson, and Cosmin Truta. W3C Recommendation, 24 June 2025. Clauses 5.2 through 5.5, 11.3.2, 13.1, and informative Annex D. This is a W3C Recommendation intended to become an International Standard, but the document explicitly says it is not yet one.www.w3.org/TR/2025/REC-png-3-20250624/
2. HTML Living Standard, Images and ImageBitmap, WHATWG, read 9 August 2026. The default color conversion is implementation-specific; none requires decoding without color conversion and ignoring embedded and display profiles.html.spec.whatwg.org/multipage/imagebitmap-and-animations.html
3. HTML Living Standard, The canvas element, WHATWG, read 9 August 2026. Used for named sRGB canvas backing stores and sRGB ImageData readback.html.spec.whatwg.org/multipage/canvas.html
4. ZLIB Compressed Data Format Specification version 3.3, Peter Deutsch and Jean-Loup Gailly, RFC 1950, 1996, section 2.2. The ADLER32 field at the end of every zlib datastream is a checksum of the uncompressed data. PNG Third Edition clause 10 uses zlib for IDAT, zTXt, iTXt and iCCP, which is why repairing a chunk CRC on one of those leaves a second checksum stale.www.rfc-editor.org/rfc/rfc1950.html
5. Encryption and Checksum Specifications for Kerberos 5, Kenneth Raeburn, RFC 3961, 2005, section 6.1.3. Used only for the security boundary that CRC-32 is neither keyed nor collision-proof. The RFC's modified Kerberos CRC is not used for PNG arithmetic.www.rfc-editor.org/rfc/rfc3961.html#section-6.1.3

Third Edition's color precedence is cICP priority 1, iCCP priority 2, sRGB priority 3, then cHRM with gAMA priority 4. Older four-item summaries that omit cICP are obsolete.