It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can.

Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.

* it actually has better compression than PNG for this

* and potentially AVIF too, but this is debated

▲ farlight 6 hours ago | parent | next [-]

avif also supports lossless, but it's so inefficient it might as well not exist.

Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.

jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.

Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.

▲ encrypted_bird 5 hours ago | parent [-]

>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.

Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.

What am I misunderstanding here?

	▲	farlight 5 hours ago \| parent \| next [-]
		Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021): https://github.com/dlemstra/Magick.NET/discussions/872 cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked: `$ cjxl src.jpg out.jxl (some output) $ djxl out.jxl rev.jpg (more output) $ cmp src.jpg rev.jpg (no output: files identical)`
	▲	pxoe 5 hours ago \| parent \| prev \| next [-]
		JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
	▲	dchest 5 hours ago \| parent \| prev \| next [-]
		It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
	▲	shakna 4 hours ago \| parent \| prev [-]
		Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool. (The IR used to be PixelPacket. Not sure how modern versions handle it.)

▲ bawolff 2 hours ago | parent | prev | next [-]

of course these are all fairly controversial claims

- people dispute it compresses meaningfully better the types of images typically found on the web.

- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.

-flexibility in file formats is usually a bad thing. look at tiff.

personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.

▲ mananaysiempre 6 hours ago | parent | prev | next [-]

> [JPEG XL can] display much larger images than AVIF can

Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

▲

sb057 4 hours ago | parent [-]

Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.

	▲	mananaysiempre 4 hours ago \| parent [-]
		I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.

▲ danielheath 5 hours ago | parent | prev [-]

One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progres... ).

If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.

A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.

The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.

Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.