PNG DPI checker: pixels, print size, transparency, metadata, and PDF placement

Three values that are often confused

The W3C PNG specification’s pHYs section says the chunk expresses intended pixel size or aspect ratio. Unit 1 means metres; unit 0 supplies only an aspect ratio. If pHYs is absent, physical pixel size is unspecified.

What GoPDFConverter’s PNG-to-PDF conversion actually does

This is more precise than saying the source PNG is “embedded directly.” The conversion is lossless at the PNG encoding stage, but it is a decode-and-re-encode pipeline. See the published testing method and the PDF 1.7 specification for the 72-point default user-space convention.

Transparency, color, and privacy signals

Truecolor or grayscale PNGs can carry a full alpha channel; palette, grayscale, and RGB images can instead use a tRNS transparency chunk. The checker reports these separately. It also reports iCCP, sRGB, gAMA, and cHRM presence without pretending that a chunk name proves calibrated output. The W3C color-space sections define their precedence and roles.

PNG can contain textual tEXt, zTXt, and iTXt chunks, plus an eXIf profile. This checker lists text keywords and flags eXIf presence without displaying potentially sensitive values. The PNG text specification explicitly includes fields such as Author, Description, Creation Time, Software, and Comment.

Reproducible PNG stress fixtures

The dataset covers three distinct cases: a 1200 × 900 RGBA image with 300 PPI pHYs, sRGB/gamma, and a text chunk; an 800 × 600 RGB image with no physical density; and a 384 × 288 indexed image with tRNS transparency and 96 PPI density. Every file has a published SHA-256 and is independently summarized by ImageMagick identify.

300 PPI RGBA fixture · RGB without density · 96 PPI indexed transparency · Expected results and SHA-256 · ImageMagick evidence

How the checker works

1. Verify the eight-byte PNG signature. A filename or MIME label alone is not accepted as proof.
2. Walk the chunk stream. The checker reads each declared length and type, then rejects chunks that run beyond the file.
3. Recalculate every CRC. PNG uses a cyclic redundancy check to detect damaged chunk type/data bytes; the W3C specification includes the algorithm.
4. Parse evidence without decoding pixels. IHDR, pHYs, transparency, profile, text, eXIf, and animation signals are read directly from the datastream.
5. Apply production placement math. A4/Letter points, orientation, and margins match the current PNG-to-PDF pipeline. Effective PPI is pixels divided by placed inches.
6. Keep the evidence portable. CSV is concise; JSON preserves the chunk inventory, CRC results, metadata flags, and exact placement values.

Limitations and assumptions

This is a structural preflight, not a color-managed raster renderer. It does not decompress IDAT pixels or ICC profiles, judge visible sharpness, validate every PNG chunk-order rule, or certify a print provider’s requirements. A valid CRC only shows that stored chunk type/data match the stored check value; it does not prove the image content is trustworthy or visually correct.

Animated PNG is flagged because a static PNG-to-PDF workflow may use only a decoded frame. Text values and eXIf contents are deliberately not displayed. Large files still consume local memory. The browser image decoder and PDF viewer remain part of the final conversion path, so representative output should be visually checked before a consequential print run.

Frequently asked questions

Use the result