Convert HEIC to TIFF

Print workflows were built around TIFF in the late 1980s and have never had a reason to move. It is the format the scanner wrote, the format the prepress software read, and the format every RIP in the building has been able to open for thirty years. Asking for it is not a preference so much as a guarantee that whatever is on the other end of the order will not have to be updated.

HEIC arrived in 2015 and is still not something a lab can assume its own systems will read — it needs an HEVC decoder, and a production machine that has run the same software for a decade will not have one. From the lab’s side, refusing the format is cheaper than debugging it at midnight with a print run waiting, and from your side, the conversion takes a few seconds.

The number that decides the print size is the pixel dimension, and it does not change during this conversion. A standard iPhone frame is 4,032 by 3,024. Divide by 300 and you get 13.4 by 10.1 inches, which is the conservative lab figure. Divide by 240, which is entirely reasonable for anything hung on a wall rather than held in the hand, and you get 16.8 by 12.6 inches.

The 48-megapixel modes on recent Pro bodies write 8,064 by 6,048, which is 26.9 by 20.2 inches at 300 ppi — genuinely large. What you cannot do is make the picture bigger by converting it: a TIFF from a 12-megapixel HEIC has exactly 12 megapixels in it, and any lab offering to "upscale for print" is running an interpolation you could have run yourself.

The file written here uses no compression at all. Every pixel occupies four bytes — red, green, blue and an alpha channel — laid down in one continuous strip, with the byte order big-endian as the original TIFF specification defined it. That is deliberately the plainest possible TIFF, because the readers that ask for TIFF are the ones most likely to disagree about anything more clever. LZW is widely supported and Deflate is not; JPEG-in-TIFF is a different picture in a TIFF wrapper. Plain uncompressed is the one dialect nothing refuses.

It is worth being clear about what that does and does not buy. Uncompressed means nothing further is discarded from this point on — you can open and resave the TIFF as often as you like without it degrading. It does not undo the HEVC compression the phone applied when it wrote the HEIC. The TIFF is a large, faithful container around a picture that was already compressed once, and that is the honest description of it.

Four samples per pixel are written, with the ExtraSamples tag set to say that the fourth is alpha. A photograph from a phone is entirely opaque, so that channel is 255 in every pixel and contributes a quarter of the file size for no information whatever.

Almost everything handles this correctly, because ExtraSamples exists precisely so a reader can tell what a fourth channel is for. The exceptions are older or narrower tools that assume three samples and hand back an error or a strangely tinted image. If a lab’s uploader rejects the file with a complaint about channels, opening it in an editor and flattening to RGB without alpha is a ten-second fix — and worth telling them about, because it is their reader that is behind.

This is the part of the conversion most likely to surprise somebody. An iPhone records in Display P3 and tags the HEIC accordingly. The TIFF produced here carries no ICC profile of any kind, so the red, green and blue values arrive with nothing to say what they mean, and every sensible reader falls back to assuming sRGB.

The visible effect is that the most saturated colours pull back a little — a red jumper, a sunset, a bright green leaf. For a family photo book this is well inside the range of variation a lab’s own printer profile introduces anyway. For a photograph where a specific colour has to be reproduced, do not use this route: ask what profile the lab wants, and prepare the file in software that can assign or convert to one.

TIFF is one of the richest metadata containers there is — EXIF, IPTC, XMP and GPS all have a defined home in it. This conversion fills none of them. The picture is decoded to raw pixels and written out again, and nothing carries the capture data across, so the capture date, the lens, the exposure and any location tag are absent.

For sending a picture to a print supplier that is mostly a small privacy gain, since a photograph taken at home no longer states where home is. It does mean the TIFF is not a record of anything: if you are keeping one file for posterity, keep the HEIC, which still has the date and the place in it, and treat the TIFF as the copy that goes to the printer.

TIFF as a format can hold up to 32 bits per channel and is routinely used at 16 for print work. What is written here is eight, because that is what comes out of the decode and there is nothing further to be had — the extra levels a HEIC can carry are quantised on the way through.

This shows up, if at all, in a large smooth gradient printed big: a clear sky across a metre of canvas can band where eight bits run out of steps. If that is the picture and the print is that size, the better path is to edit the HEIC in software that works in 16 bits and export the TIFF from there. For anything with texture in it — people, streets, landscapes with detail — eight bits is what a print shows anyway.

A single 12-megapixel TIFF is 48.8 MB, and that is before you have twenty of them. Many lab uploaders cap individual files at 50 or 100 MB and some cap the whole order, so it is worth checking the number before converting a shoot rather than after. A 48-megapixel frame at roughly 195 MB will exceed a good many of them on its own.

Drop the whole selection here at once — each file is handled separately with its own progress and the set can be taken as a single ZIP. Input files are accepted up to 100 MB on the free tier, which no HEIC comes close to; the size that matters on this pair is the one coming out.

If the lab’s form lists JPEG as well as TIFF, and the picture came off a phone, JPEG at high quality is a defensible choice and a far more practical one. The source was lossy already, a good JPEG adds a second pass that is invisible at print sizes, and the file is a fiftieth of the size, which means the order actually uploads.

The case for the TIFF is when the file will be worked on after it arrives — retouched, colour-corrected, composited into a book layout and saved several times — because each of those saves would cost another JPEG generation. Ask which it is. A lab printing straight from the file wants it small and correct; a designer building a book wants it uncompressed.

The decode runs on libheif compiled to WebAssembly and the TIFF is assembled by JavaScript, both in the page you have open. No request carries the image, which you can confirm by opening the developer tools and watching the network tab through a conversion, or by disconnecting and converting anyway.

That matters more than usual here, because the photographs people send to print are the ones of their children, their wedding and their house. A free converter that uploads is asking you to trust an unnamed server with exactly that set, and the arithmetic of 48 MB per file makes the upload slow as well.