Convert ICO to JXL

This was measured rather than reasoned about. A test icon converted here produced a valid 4,348-byte JPEG XL, and handing that file straight back to the same browser’s image decoder failed with "The source image could not be decoded". Chrome shipped JPEG XL behind a flag, then removed it in 2023; Safari is the major browser that reads one today.

The situation is genuinely odd and it is not a bug on this page: encoding and decoding are separate pieces of software, and the encoder here is a WebAssembly module that ships with the page rather than something the browser provides. It does mean you should not expect to preview the result by dragging it into a tab, and it rules the format out for anything served to visitors.

JPEG XL was designed around two things that matter enormously in archives and hardly at all on a favicon: it can re-encode an existing JPEG losslessly, cutting roughly a fifth off a photographic library without touching a pixel, and it supports very high bit depths and enormous dimensions for long-term storage of scanned and photographic material.

An icon offers it neither. There is no JPEG to transcode, no gradient to model, no bit depth beyond eight and no dimension beyond 256. What is left is a general-purpose encoder applied to a small flat drawing, which is the content type every modern codec handles worst.

The same 256-pixel test icon through every target this site writes, at default settings: 1,737 bytes as PNG, 1,894 as GIF, 3,054 as WebP, 3,624 as AVIF, 4,005 as JPEG and 4,348 as JPEG XL. The most modern format produced the largest of the compressed results.

That ordering is specific to small flat artwork and it reverses on a photograph, where JPEG XL and AVIF pull well ahead. Quoting the photographic result as a reason to convert icons is the mistake this section exists to prevent.

JPEG XL has two legal file forms. The bare codestream begins with the two bytes FF 0A. The container form wraps the same codestream in an ISOBMFF box structure beginning 00 00 00 0C 4A 58 4C 20, which is what lets a file carry Exif, XMP and an ICC profile alongside the image.

The files written here are the bare codestream form, confirmed by reading the first bytes of the output. Both are valid and libjxl reads both, but a strict ingest process configured to expect the container will reject one that has no boxes in it. If a pipeline refuses the file, check this before assuming the encoder is at fault.

The alpha channel is supported by the format and carried through the conversion, so a cut-out mark does not acquire a background the way it does on the GIF path. That much works as expected.

What is not offered is a lossless switch. The quality control starts at 82 and the pair is classified as lossy, which is an accurate description of what the encoder is being asked for. JPEG XL has a genuine mathematically lossless mode and this page does not expose it — so if the reason for the conversion is archival fidelity, PNG is lossless by construction and requires no setting to get right.

The largest. Your browser decodes the icon and returns its biggest entry, checked by constructing a file holding 16, 32, 48 and 256 pixel drawings in four separate colours and converting it with the directory ordered three different ways. The 256-pixel drawing came out each time.

For an archive that is a meaningful loss. The point of an icon file is often that somebody hand-drew the 16-pixel version, and it is precisely that drawing which disappears. If the archive is meant to preserve the asset rather than a picture of it, keep the ICO itself.

GIMP and ImageMagick both read JPEG XL today and both are the kind of software that stays around, which is the strongest argument for the format in a tool chain. libjxl is open source and the specification is published as ISO/IEC 18181, so the decoder is not going to become unavailable in the way a proprietary one might.

Against that: the format has been standardised since 2021 and its browser support has gone backwards rather than forwards in that time. Archival formats are chosen for the confidence that something will read them, and on that specific measure PNG and TIFF are still ahead of JPEG XL by a wide margin.

The case for is uniformity. If a collection already holds thousands of photographs as JPEG XL, converting the handful of icons in it means one decoder, one ingest rule and one thing to test, and a couple of extra kilobytes per icon is not worth a second code path.

The case against is that icons are the part of that collection where the format helps least and the loss is largest, since the container’s other entries do not survive. A reasonable middle is to keep the original ICO files as the record and treat the JXL as a derived preview, which is how most archives handle formats they cannot fully represent.

Drop the whole folder and each file is encoded on its own, with everything returned as a ZIP. The JPEG XL encoder is one of the two large WebAssembly modules on this site, so the first file pays for the download and the rest are quick.

Check a sample of the results in whatever will consume them before converting the rest. Given that the browser may not display a JXL at all, the usual habit of opening one to confirm it looks right does not work here, and a batch that silently produced files nothing in your pipeline accepts is an expensive thing to discover late.