Convert AVIF to TIFF

AVIF was published in 2019 by the Alliance for Open Media to carry pictures over a network as cheaply as possible. TIFF was published by Aldus in 1986 — Adobe acquired it with the company in 1994 — to hand images between professional systems without ambiguity. Neither is a better format; they are answers to different questions, and this conversion moves a file from one question to the other.

That is why the size difference is not a defect to be worked around. Every byte AVIF saves is a byte of certainty it traded away, and every byte TIFF spends buys back a guarantee that the next application reads the same pixels. A print shop asking for TIFF is buying that guarantee deliberately, and it has four decades of evidence behind the choice: the format dates from 1986, the TIFF 6.0 specification everything is written against has not needed replacing, and files from that era still open. AVIF has not existed long enough to make any such claim.

If the AVIF was written lossily, and a web-delivered one always is, the detail its encoder discarded is gone before this page sees the file. The TIFF stores what remains, exactly, and stores it forever. That is a real guarantee about everything that happens next and no guarantee at all about what happened before.

The distinction decides whether the exercise is worth doing. If a picture desk asked for TIFF in order to protect image quality, converting an AVIF meets the letter of the request and not its purpose — the quality was already spent when the site encoded the file. Where the camera original or the editor export still exists, converting that is what was actually wanted, and it is worth one conversation before spending the disk space. Where it does not, this is the best answer available and worth doing: the TIFF still stops any further degradation, which is a real benefit even when the first round has already been paid.

Uncompressed means the size is determined entirely by the pixel dimensions: width times height times four bytes, plus a small header. A 3000 by 2000 image is 24 MB. A 6000 by 4000 image is 96 MB. What the picture contains makes no difference whatsoever.

AVIF sits at the other extreme, and that is what makes this pair so lopsided. A web-sized photograph that AVIF stored in a few hundred kilobytes becomes tens of megabytes with no visible change, so the multiplier here is commonly fifty and can exceed a hundred on flat artwork, where AVIF is at its most efficient and TIFF is exactly as expensive as ever. The only lever that moves it is the maximum width setting, which changes the picture rather than the compression, and which is usually the wrong thing to touch when a specification is being answered. If the resulting file is too large to send, the problem to solve is the transfer rather than the format.

AVIF can hold twelve bits per channel and a wide colour gamut, which is why it is used for HDR photography on the web. TIFF as a specification goes further still — up to thirty-two bits per channel, with CMYK and Lab alongside RGB.

The file written here is eight-bit RGB, so neither format is being used to its ceiling. For an ordinary web image that is exactly right, because eight bits is all the source ever carried and writing sixteen would only pad each value with zeros. For a genuine HDR or wide-gamut AVIF it is a real reduction, and the symptom is a highlight that clips flat rather than rolling off. If the specification you are answering names a bit depth or a working colour space, this conversion does not satisfy it, and the right tool is an application that lets you choose how the range is mapped rather than one that decides for you.

Print workflows frequently expect CMYK, and TIFF is one of the few image formats that can carry it. What comes out of this conversion is RGB, because that is what the AVIF held and inventing an ink separation would mean guessing at a press profile nobody supplied.

That is the right default rather than a limitation. A separation depends on the paper, the press and the ink set, and the shop holding those profiles will do it better in a second than any converter can do it blind. Send a correct RGB TIFF and let them separate it; a wrongly separated file is harder to fix than an unseparated one, because the conversion is not reversible and the errors show up as muddy blacks and shifted skin tones after the plates are made. Say in the covering email that the file is RGB, which is the sentence that prevents the whole misunderstanding.

AVIF has a full alpha channel and TIFF has one too, so a cut-out logo or a product shot on a transparent background arrives as a cut-out rather than being flattened onto white. Anyone who has converted a JPG to TIFF will not have met this, because a JPG has no transparency to bring.

It is worth a decision rather than a shrug. Ink is opaque, so somewhere between your file and the sheet the transparent areas become something — and the person who decides that should be you, in a tool where you can see the result, rather than whichever application in the chain reaches the file first.

AVIF is read by current browsers and by a short list of applications: GIMP, Squoosh and ImageMagick handle it, and a great deal of professional and older software does not. That is precisely why the request for a TIFF arrives.

TIFF inverts the situation exactly. Only Safari displays one, so a TIFF is useless on a web page — and every scanner, prepress system, imaging library and archive tool made in the last three decades reads them without being asked twice. Photoshop, Affinity Photo and ImageMagick are the ones people name, and the list of things that quietly support TIFF is longer than the list of things that support anything else on this site.

Every image conversion in this browser decodes the picture to raw pixels and writes a new file from them, so the EXIF block in the source is not carried into the output. Nothing that was in the AVIF about the device, the timestamp or the coordinates survives the trip.

For a submission that is usually welcome and one less thing to remember to strip, particularly where the image was taken somewhere the coordinates should not follow it. For an archive deposit it is a genuine loss, because provenance is half of what an archive is storing and a picture without a date is worth noticeably less than the same picture with one. If the metadata is part of the requirement, record it in the accompanying sheet or work from the original in an application that migrates the tags, and do not assume a converter of any kind has carried them.

TIFF can hold many images in one file, which is how scanners deliver a stack of pages, and this conversion does not produce that. Each AVIF becomes its own single-image TIFF.

Since an AVIF holds one picture, nothing is being dropped by writing one image per file. It matters only when the requirement was for a multi-page TIFF of a scanned document, in which case the source material is a set of pages and the assembly step belongs in the tool that will bind them rather than in a per-file converter. Where the destination will take a PDF instead, that is usually the easier route to a single multi-page deliverable and the recipient is more likely to be able to read it.

Drop a folder and the results come back as one ZIP, with nothing uploaded, a hundred files to a batch and 100 MB per file. The tighter constraint is arithmetic: thirty 6000 by 4000 images are close to three gigabytes of TIFF being assembled inside a browser tab.

Work in small groups and save as you go rather than dropping a season of work in at once. It is also worth keeping the AVIF files afterwards. They are a fraction of the size, they are what you will want if the requirement changes or the submission is rejected, and the TIFF is a delivery artefact rather than an archive of its own. Deleting the smaller file because the larger one is now the official copy is the version of this mistake that costs the most storage for the least benefit.