Convert TIFF to JXL

The reason this pair gets searched is a good one: JPEG XL is genuinely a strong archival candidate. It stores up to 32 bits per channel, has a true lossless mode, handles wide-gamut colour, and compresses better than anything else in its class. Several national libraries have looked at it seriously for exactly that reason.

None of that reaches you through this converter, because the pipeline in between is 8-bit RGB and the encoder is driven by a quality number. What you get is a small, good-looking, lossy derivative — useful for many things and not a master. An archival copy has to be bit-exact, full depth and colour-managed, and this route is none of the three. If the collection matters, keep the TIFF and treat what comes out of this page the way you would treat a JPG of the same scan.

The quality control runs to 100 and the encoder behaves differently at the top of the range, so it is worth knowing what the number buys rather than assuming. Measured through this site’s own encoder on a 256 by 256 test image: at the default 82, a gradient came back with 73,647 of its 262,144 samples changed, the worst by 21 levels. At 100, 334 samples differed and none by more than one level; flat artwork at 100 came back bit-identical.

That is near-lossless rather than lossless, and it is a meaningful distinction for an archive and an irrelevant one for a proof. Practically: leave it at 82 for anything you are looking at, set it to 100 if the file is going into a workflow that will re-encode it again later, and do not describe the result as a lossless copy in a catalogue record. The encoder’s dedicated lossless mode exists in the library and is not exposed by this converter.

A great many TIFFs are 16-bit — that is most of the point of scanning to TIFF, and it is what gives a scan headroom for levels and curves afterwards. The reader used here decodes 16-bit files correctly and then hands on 8 bits per channel, keeping the high byte of each sample. Measured on a 16-bit greyscale TIFF: a stored value of 30,000 arrives as 117.

On a finished picture nobody can see the difference, because a screen shows eight bits and the eye does not do better. On an editing master it is the whole difference: the smooth 16-bit gradient that survives a heavy curve adjustment is exactly what has been thrown away, and pushing the levels on the 8-bit result will band. If you scanned at 16 bits deliberately, that decision does not survive this page.

A TIFF from a print workflow is often CMYK with an ICC profile attached, and that pair of facts is what makes it printable. The reader here converts CMYK to screen colour with a fixed formula rather than through the embedded profile, so the result is recognisably the same picture in slightly the wrong colours — usually flat in the deep shadows and a little cool where the profile would have compensated.

The profile itself does not travel either. Every image conversion on this site decodes to raw pixels and re-encodes, so ICC, EXIF, XMP, IPTC and GPS blocks are all dropped, and that is unconditional rather than a choice the page puts in front of you. For a print asset that is a genuine loss and it is the second reason not to treat this as an archival migration. For a picture on a screen it costs nothing.

TIFF holds more than one image per file and document scanners use that constantly. JPEG XL as produced here holds one. The reader takes the first page and stops, with no error and nothing in the interface to say that pages two onwards existed.

That is the one way this conversion can go quietly wrong on a whole collection at once, and it is worth checking before a batch rather than after. If the TIFFs came from a document scanner, a fax gateway or a records system, assume they may be multi-page and open a few. Splitting is a one-line job in ImageMagick or a menu item in IrfanView. Where the pages belong together, TIFF to PDF is the page that keeps all of them in one file.

Very much smaller, because the starting point is uncompressed. This site’s own samples at 480 by 320 are 615,400 bytes as TIFF in every case; as JXL at the default quality they are 7,240 bytes for the photograph, 13,252 for the screenshot-like scene and 5,016 for the flat graphic.

The photographic figure is the interesting one: 7,240 bytes is the smallest of every format in that sample set, below WebP’s 14,700 and AVIF’s 17,599. JPEG XL really is the strongest codec of the three on continuous tone at this quality, and if the only question were bytes-for-quality it would win. The question is never only that, which is what the next section is about.

This is where JPEG XL loses, and it is why the format is marked as niche rather than current. Browser support is partial rather than universal, so a .jxl is not a file to put on a web page or attach to an email without knowing what the other end runs. GIMP and ImageMagick handle it; Photoshop needs a plug-in; a great deal of ordinary software simply shows an unknown-file icon.

That narrows the honest use to two situations. The first is a closed workflow — your own tooling, your own storage, a pipeline that named the format. The second is somebody experimenting deliberately, with the original safely kept elsewhere. Anything that has to be opened by a person you have not spoken to should be a WebP, a JPG or a PNG instead, and the sibling pages cover all three.

If the goal was a smaller archival copy that stays exact, TIFF to PNG is the honest version of that idea: PNG is lossless within eight bits, every piece of software on earth reads it, and on flat scanned content it is often smaller than a high-quality lossy file anyway. It does not keep 16 bits either — nothing here does — but it does not lose anything else.

If the goal was publishing, TIFF to WebP works in every browser and TIFF to AVIF is smaller on flat scanned material and lifts the pixel ceiling. If the goal was sending the scan to a person, TIFF to PDF or TIFF to JPG is what they are expecting to receive. And if the goal was a genuine archival master, the correct answer is the one nobody likes: the TIFF you already have is the archival master, and it should be kept.

utif2 decodes the TIFF and libjxl compiled to WebAssembly writes the JXL, both fetched only when they are needed. Nothing about the file crosses the network, which is the practical reason an archive can use this page on unpublished or restricted material at all. The free limit is 100 MB per file, roughly a 600-dpi A4 colour scan stored uncompressed.

Batches run the same way: drop a folder, each file gets its own progress row, the results come back as a ZIP. JPEG XL encoding is not as slow as AVIF but it is not instant either, so a large run is worth starting and leaving. The engine downloads once and is reused for the rest of the batch.