Convert JXL to TIFF

TIFF has been in use since Adobe published it in 1986 and the current specification, TIFF 6.0, has been stable since 1992. Everything in the print, scanning and preservation world reads it, most institutional ingest specifications name it explicitly, and no piece of professional imaging software will refuse one. That longevity is the requirement, not the compression.

JPEG XL is fifteen years younger than the software some of those workflows run on. It is genuinely the better archival codec on the technical merits — lossless mode, up to 32 bits per channel, wide-gamut colour — and none of that helps when a repro house tells you their prepress system takes TIFF. This conversion is compliance, and it is worth doing on a copy rather than on the original. Keep the JPEG XL in the same folder: it is smaller than the TIFF by an order of magnitude and it holds strictly more information.

TIFF is less a format than a filing system for images, and its readers agree on less than you would hope. LZW is patent-free and universally supported, Deflate is not universally supported, and JPEG-in-TIFF is a different image inside a TIFF wrapper. This converter writes the plain uncompressed baseline: one strip, four samples per pixel, eight bits each, compression tag set to none.

That is the variant nothing rejects, which matters because somebody converting to TIFF is almost always feeding a specific machine rather than storing something for themselves. The cost is the entire size of the file, and it is not a small cost. If your requirement explicitly permits LZW, a dedicated tool such as ImageMagick will produce a considerably smaller TIFF than this page does. The choice made here is deliberate: a file that is too large is a nuisance, and a file the prepress system cannot open is a missed deadline.

The arithmetic is simple because there is no compression in it: four bytes per pixel, plus a header of a thousand bytes. A 4,000 by 3,000 pixel image is 48,001,000 bytes — roughly 46 MiB — whether it is a photograph of a forest or a white rectangle. A 24-megapixel frame from a full-frame camera comes to about 92 MiB.

A JPEG XL of the same picture might be three megabytes. That is a factor of fifteen or more, and it is the correct behaviour rather than a defect: an uncompressed TIFF is what it is precisely because nothing has been decided about the pixels. Plan the disk and the transfer accordingly, and prefer a ZIP for sending, since the LZW-shaped redundancy that TIFF is not exploiting is exactly what a ZIP will find.

TIFF as a specification handles CMYK, Lab and greyscale as readily as RGB, and that breadth is part of why print workflows standardised on it. The file this converter writes is RGB with an alpha sample, and nothing on this page will produce a separation.

If the specification you were sent says CMYK with a named profile — a coated stock profile, a house standard — this conversion does not satisfy it and no setting here will. Separation is a colour-managed operation that depends on the output profile, and it belongs in Photoshop or Affinity Photo where that profile exists. Where the requirement is simply "supply TIFF", which is the more common case for photographic and archival submissions, RGB is what they expect, and handing a printer an RGB TIFF they will separate themselves is normal practice rather than an error.

Both formats reach 32 bits per channel on paper, so this pair could in principle move a high-bit-depth image without touching it. In this converter it cannot. The JPEG XL decoder returns 8-bit RGBA and the TIFF writer stores exactly those samples, so the output is 8 bits per channel however the source was encoded.

For a scan headed to print or an image going into a photographic archive that is generally sufficient — 8-bit RGB is the working depth of most print pipelines. Where it is not sufficient is a file you intend to grade or heavily correct afterwards, because 8 bits is where banding appears once curves are pushed. In that case keep the JPEG XL as the master and convert to TIFF only at the moment of handover.

The output carries four samples per pixel with the fourth marked as an alpha channel, so a transparent JPEG XL arrives with its transparency intact rather than flattened onto a colour. That is a real advantage over converting to JPG or BMP, where the alpha has to be filled in and the fill is permanent.

The honest qualification is on the reading side. TIFF support for extra samples is inconsistent across the older software that still drives print and scanning workflows, and a reader that ignores the flag will composite the image against black or white without telling you. If the file is going somewhere transparency matters, open the TIFF in the destination software before you send four hundred of them.

A TIFF can record how many pixels correspond to an inch, and layout applications read it to decide how large a placed image starts out. The file written here reports 72 with the resolution unit set to none, which means the number carries no physical meaning at all — it is a placeholder that keeps older readers from rejecting the file.

The practical consequence: nothing in the TIFF tells anyone to print it at 30 centimetres wide. The pixel dimensions are the only measurement that travels, so agree the size in pixels with whoever is printing, or set the physical dimensions in InDesign, QuarkXPress or whatever lays the page out. A 4,000-pixel edge is about 34 centimetres at 300 dpi, and that arithmetic is the conversation worth having up front.

Multi-page TIFF is one of the format's genuinely useful features — it is how a fax, a scanned contract or a whole book chapter arrives as one file. This conversion writes a single image directory, because a JPEG XL holds one picture and one picture is one page.

Where a workflow expects a multi-page TIFF, the assembly step is separate and belongs to a tool that can take several images and stack them. Converting a folder here gives you a folder of single-page TIFFs, correctly formed and individually acceptable, which is the right input to that step rather than a substitute for it.

The arithmetic gives you a free verification. An uncompressed TIFF from this converter should be almost exactly four times its pixel count in bytes — a 3,000 by 2,000 file is 24,001,000 — so a size that is far off means the image dimensions are not what you assumed, usually because a maximum width was left set from a previous run.

Then open one in the software that has to accept them, not in a viewer that accepts everything. That is where a specification is really tested: whether the alpha sample is honoured, whether the uncompressed variant is what the ingest expects, whether the pixel dimensions meet a minimum. Five minutes on the first file is cheaper than re-running a batch of four hundred and re-sending them.

Safari has displayed TIFF for as long as it has used ImageIO; Chrome, Firefox and Edge never adopted the format and will not display one, which is why the file has to be decoded by dedicated code on the way out rather than handed to the platform. If your destination is a web page, this is the wrong conversion entirely and WebP or AVIF is the right one.

The conversion still runs entirely on your own machine — the decoding, the pixel work and the TIFF write all happen in the browser tab, and files up to 100 MB are accepted on the free tier without an upload. For images going into an archive or to a printer that is the property that matters most, because those files are usually the ones somebody is being careful with. It also means the size of the output is bounded by your own disk rather than by an upload allowance, which matters when a folder of fifty images becomes two gigabytes of TIFF.