Convert PNG to TIFF

Nobody converts a PNG to a TIFF to make it better. They do it because a specification names TIFF: a commercial printer preparing plates, a journal with figure requirements written in 2004 and never revised, a GIS package, a microscopy or medical-imaging pipeline, a records system whose ingest rules predate PNG entirely.

That makes this a container change and nothing else. The right outcome is that the picture is bit-for-bit the same and the wrapper is different, which is what happens here — the value is in being accepted, not in being improved.

PNG and TIFF sit on the same side of the important line: neither of them throws information away. A PNG stores exact pixels and compresses them with a scheme that can be perfectly reversed; this TIFF stores the same exact pixels with no compression at all. The picture that comes out is the picture that went in.

This is worth stating because so many conversions do cost something, and people arrive expecting to weigh a trade-off. Here there is none to weigh. The only quantity that changes is the size of the file.

The TIFF written here is uncompressed baseline RGBA — every pixel as four plain bytes, no encoding wrapped around it. That is chosen deliberately: it is the one variant of TIFF that every reader accepts. LZW and JPEG-in-TIFF are smaller and are precisely where elderly print software and archive tools start rejecting files.

So the size follows straight from the pixel count and ignores the content. A 2000 by 2000 image is roughly 16 megabytes whether it is a photograph or a flat white square, where the PNG of that white square would be a few kilobytes. It is normal, it is not a fault, and it compresses very well if you need to email it — a ZIP of uncompressed TIFFs is dramatically smaller than the TIFFs.

The alpha channel is carried into the TIFF intact, so a cut-out product shot or a logo with soft edges keeps them. Modern imaging software reads that correctly.

Print workflows are the exception worth asking about. A number of RIPs and older layout tools ignore alpha in a TIFF and composite everything onto white, which is fine for a logo destined for a white page and wrong for one going onto colour. If the artwork depends on transparency, say so when you hand the file over, or flatten it onto the intended background yourself first.

PNG files usually carry no meaningful DPI value, and a conversion cannot invent one — DPI is a statement about physical size, and the image does not know how large it will be printed. What decides print quality is the pixel count.

The arithmetic is simple: to print at 300 dpi across A4 you need about 2480 by 3508 pixels. If your PNG has them, the TIFF prints beautifully; if it is a 600-pixel screenshot, converting to TIFF does not add detail and it will look soft at any size. Check the pixel dimensions before the format.

The output is an RGB TIFF. Commercial printing is normally CMYK, and the conversion between the two is not arithmetic — it depends on a profile matched to the press, the ink and the paper, and picking the wrong one shifts colours in ways that only become visible once several thousand copies exist.

Every print shop expects to handle that separation themselves, from an RGB file, using the profile for the job in hand. Handing them RGB is the correct thing to do rather than a shortcoming.

Figure sets, icon libraries and scan batches are never a single file. Drop the whole folder: each PNG converts in turn on your own machine with its own progress, keeps its filename with the extension swapped, and the results come back together as one ZIP.

Because none of it is uploaded there is no queue, no per-file wait for a server and no daily allowance to run out of halfway through a submission. The two limits that do apply are the free tier's and they are worth knowing before a large folder: 100 MB per input file, and 100 files at once in one drop.

The TIFF is for whoever asked for it. The PNG remains the better file to work with, store and send: identical pixels, a fraction of the size, and opened by everything from a phone to a browser.

Treat the TIFF as a delivery format rather than an archive one. Nothing is lost in either direction, so the conversion can be repeated whenever the next specification asks for it.