When a PNG is the right copy of a TIFF
PNG stores exactly the pixels it is given and every browser shows it, which makes it the natural lossless copy of a TIFF. Reach for it for scans of text and line drawings, for screenshots and graphics that were saved as TIFF, for pictures with transparency, and as a working copy for editing, where a lossy JPG would add damage each time it is saved.
For a photograph that is only going to be looked at, a JPG is far smaller: our 3 megapixel photo was 4.5 MB as a PNG and 683 KB as a JPG. TIFF to JPG makes those. A PNG cannot hold CMYK or several pages, and the ones made here have 8 bits per colour, so those parts of a TIFF do not come across.
What we checked, layout by layout
TIFF is less one format than a family, and decoders often get a rare layout wrong. We rewrote one test picture many ways with libtiff's tiffcp, tifffile and Pillow, converted each file here, and compared the PNG with the known pixels. As a second check, libtiff's own tiff2rgba gave the same pixels as those references for 72 of the 81 files where the two can be compared.
- Pixel for pixel identical: uncompressed, LZW (with and without the predictor), ZIP, PackBits, strips of one row up to the whole picture, tiles that do not divide the picture evenly, colours in separate planes (8 and 16 bit), big endian and little endian files, 16 bit, 32 bit floating point grey, grey, 2 bit grey, black and white (CCITT group 3 and 4, run length, PackBits, LZW), palette, CMYK, and the eight orientation tags.
- Within 1 level: six embedded RGB profiles converted to sRGB and compared with LittleCMS, a 16 bit file whose low bytes carry real values, and TIFF files that hold JPEG data with RGB colour.
- Different, and how: a JPEG TIFF with subsampled colour differed from libtiff by 3.6 levels on average on a deliberately harsh test picture, with no overall colour shift: it was no further from the original picture than libtiff's own result. A CMYK file with an embedded profile differed from a profile based conversion by 18 levels on average, because the profile is not used.
Transparency was identical in all nine test files with an alpha channel, including grey with alpha and 16 bit files. The colours of partly transparent pixels can shift because browsers store them multiplied by alpha: by at most 2 levels where alpha is 50 percent or more, at most 4 between 25 and 50 percent, and more below that.
Sizes you can expect
PNG suits scans, graphics and line work, and is heavy for photographs. An uncompressed 9.0 MB photo became 4.5 MB, about half. The same photo stored as LZW with the predictor was already 5.5 MB, so the PNG saved only 18 percent. At 24 megapixels the optimiser is switched off to keep things fast, and a 25.9 MB LZW TIFF grew to 35.6 MB, 37 percent larger. The list marks such files.
Scans are where PNG shines. The 3.7 MB grey scan of an A4 page became 133 KB, and the 473 KB uncompressed black and white version became 37.9 KB. The black and white page already stored with CCITT Group 4 took 36 KB, so its PNG was 5 percent larger, the one case where the PNG was not smaller.
What the PNG leaves behind, and what it will not open
The PNG has 8 bits per colour. It carries no colour profile, no print size (dpi) and none of the TIFF text fields such as artist, copyright or description, even with Keep selected under Metadata. Only the largest page of a multi-page file is converted.
Some layouts are refused with a message instead of a wrong picture: compressions such as ZSTD, LZMA and WebP, JPEG compressed files with separate colour planes, signed integer samples, 4 bit grey, bits stored from the low end of each byte outside fax compressions, and BigTIFF. A file cut short by an interrupted download is reported as cut short.