Convert TIFF to AVIF

This is the concrete reason to be on this page rather than on TIFF to WebP. WebP stores its dimensions in fourteen bits and cannot exceed 16,383 pixels on either edge; measured against the encoder used here, 16,383 pixels encodes and 16,384 fails outright. AVIF’s ceiling is 65,536.

Scans reach those numbers routinely while photographs never do. A 600-dpi A1 sheet is about 14,000 by 19,900 pixels, an A0 sheet at 400 dpi about 13,200 by 18,700, and an A3 page captured at 1,200 dpi about 14,000 by 19,800 — all three over the line. If the point of the scan was to preserve the detail, being forced to halve it to fit a container is a real loss — and it is the loss AVIF removes.

The second reason is efficiency, and it is content-dependent in a way that is worth measuring rather than assuming. This site’s three sample scenes, encoded at 480 by 320 through the same pipeline this page uses, come out as follows: the screenshot-like scene is 5,081 bytes as AVIF and 10,830 as WebP; the flat graphic is 3,494 against 4,428; and the photograph is 17,599 as AVIF against 14,700 as WebP.

So AVIF halves the flat one and loses on the photograph. That is not an anomaly — AV1’s intra prediction is very good at large regions of near-constant colour separated by hard edges, which is a description of a scanned document, a plan, a page of type or a music score. It is less obviously better on continuous tone at a moderate quality setting. If the TIFF is a photographic scan and you want a straightforward answer, TIFF to WebP is that answer; if it is paper, this page is.

AVIF is supported by modern browsers, which is not the same as all of them. Someone on an old phone, a locked-down corporate machine or an unusual client can land on a page and see an empty box, and unlike a missing font or a slow script that failure is total.

On a public page the answer is a picture element with an AVIF source and a WebP or JPG fallback, which costs one extra export and removes the problem entirely. For a file you are emailing or handing to a colleague there is no fallback mechanism, so the question is simply whether you know what will open it. That is the whole trade, and it is why WebP remains the default recommendation on the sibling page rather than this one.

AVIF is AV1 still-picture coding, and AV1 spends a lot of computation deciding how to describe each block. On a large scan the encode dominates the conversion — decoding a 100-megabyte TIFF is fast by comparison — and a very large image can take tens of seconds in the tab.

That cost is paid once, by you, at conversion time. Every visitor afterwards pays only the download, which is the half of the transaction that matters on a phone over a slow connection. It does mean a batch of scans is a coffee rather than a keystroke, and it is worth reducing the pixel dimensions first if the published image does not need to be 20,000 pixels wide — most do not. There is no control here that trades encoding effort for speed, so the way to make a large run finish sooner is to reduce the pixel dimensions rather than to ask the encoder to work less hard. A phone will manage it and will manage it slowly; a desktop is the right machine for a collection of scans.

The quality control runs from 1 to 100 and starts at 82. On a photographic scan that is a sensible balance. On scanned type it is not the setting to leave alone: text is thousands of hard black-on-white transitions, which is what any lossy codec smears first, and the symptom is a soft grey shimmer around every letter that makes a page look photocopied.

Raise it to 90 or above for anything with type or fine rules in it. The file grows and stays far smaller than the TIFF, and the difference in readability at a normal zoom level is obvious. Where the document has to remain pixel-exact — a signature, a survey with dimensions on it, a table of figures being cited — no lossy setting is correct and TIFF to PNG is the page for that job.

AVIF can store twelve bits per channel and wide-gamut colour. This converter cannot give it any of that, because the pipeline decodes every source to 8-bit RGB. A 16-bit TIFF is reduced by keeping the high byte of each sample, and a CMYK TIFF is converted to screen colour by formula rather than through the ICC profile embedded in the file, so a press-ready scan comes out shifted.

Two container features go the same way. A multi-page TIFF contributes its first page only, with no error raised, so a scanned drawing set has to be split before converting. Layers are flattened. None of that harms a picture destined for a web page, which is 8-bit sRGB and single-image by definition — it harms you only if the TIFF was the master. Keep the TIFF, publish the AVIF.

AVIF carries a full alpha channel, so a cut-out or a masked region in the TIFF arrives intact with soft edges still soft. That is one of the ways this route beats the old habit of converting scans to JPG, which fills transparency with a background colour and cannot do anything else.

Metadata goes the other way and does so unconditionally. EXIF, XMP, IPTC, the ICC profile and any GPS block do not survive a decode-and-re-encode, and there is nothing on the page that keeps them. For published scans that is the right outcome: an archive image should not be carrying an operator name and a machine serial number, and a caption belongs in the page rather than in the file.

If the image must work everywhere with no fallback arrangement, TIFF to WebP is the page — every current browser reads WebP, and on photographic content it was smaller here than AVIF anyway. If the file has to reach somebody’s email or a print shop, TIFF to JPG is what they are expecting.

If nothing may change at all, TIFF to PNG keeps every pixel exactly and remains readable by everything; and TIFF to PDF is the right move for a scanned document that will be filed or sent rather than displayed, because it is the only one of these that keeps more than one page. Choosing AVIF is worth doing when the image is large, flat and public. It is worth skipping otherwise.

Everything runs in the tab. utif2 decodes the TIFF, libavif compiled to WebAssembly encodes the AVIF, and both are fetched only when a file of that type is dropped. Nothing about the image crosses the network, which matters for archive material that has not been published yet and for anything under an embargo or a licence.

The free ceiling is 100 MB per file, about a 600-dpi A4 colour scan uncompressed; larger scans need to be reduced first, which is on the same options panel. Batches work: drop a folder, watch each row, take a ZIP at the end. Because AVIF encoding is the slow step, a large batch is genuinely slow — a run of full-size scans is worth starting and leaving alone rather than watching.