Chromium 143 (the latest available in Void Linux, a rolling-release distro) still can't.

The chrome://flags/#enable-jxl-image-format is not even found in the build :(

> Hopefully my photo processor will accept JPEG XL in the near future!

Aren't print shops, machining shops, other small manufacturers etc. ones that always lag behind with emerging technologies?

Working fine on Firefox for me

Firefox version 146.0.1 on Windows 11

Works in Zen 1.17.15b (aka Firefox 146.0.1) on Linux.

Same here, doesn't work, FF 148.0b5

I understand why people avoid it now; however, having not seen the uncropped version for a long time initially, I have only warm associations.

Weird, doesn't work in Brave (macOS) for me. Did you enable a setting? Brave says it's up to date when I check.

Doesn't work for me on Brave on Android

WPE can be built for Android, but it’s not a user facing browser.

The closest thing I know of is Igalia has a project trying to port https://wpewebkit.org/ to Android https://github.com/Igalia/wpe-android and they have a minibrowser example apk in the releases of the current state (but I wouldn't call it a Chrome drop in replacement or anything at the moment - just the closest thing I know on Android).

Do you have anything to back this up?

Considering "jpeg" has become the shorthand for "digital picture", it would be a shame not to capitalise on it.

I found it unfortunate because it's not a JPEG.

μJPEG

Crappy as a .jpg, only bigger.

Actually, I remember when JPEG XL came out, and I just thought: cool, file that one away for when I have a really big image I need to display. Which turned out to be never.

Names have consequences.

That’s because it uses the WebKit renderer built in to iOS

Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0].

> "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.

> JPEG XL support in Safari actually comes from the underlying OS rather than the browser. My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought. I'm just guessing though.

> The implementation that was in Chromium behind a flag did support progressive rendering to some degree, but it didn't render anything until ~60 kB (39% of the file). The rendering is similar to the initial JPEG rendering above, but takes much more image data to get there. This is a weakness in the decoder rather than the format itself. I'll dive into what JPEG XL is capable of shortly.

> I also tested the performance of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder is about as slow as the Safari decoder. It's not fair to judge the performance of experimental unreleased things, but I was kinda hoping one of these would suggest that the Safari implementation was an outlier.

> I thought that "fast decoding" was one of the selling points of JPEG XL over AVIF, but now I'm not so sure.

> We have a Rust implementation of JPEG XL underway in Firefox, but performance needs to get a lot better before we can land it."

[0]: https://jakearchibald.com/2025/present-and-future-of-progres...

Why use AVIF when JPEG XL is much better and in a few weeks almost universally supported?

Because JPEG XL is the first format to actually bring significant improvements across the board. In some aspects AVIF comes close, in others it falls far behind, and in some it can’t even compete. There’s just nothing else like JPEG XL and I think it deserves to be supported everywhere as a truly universal image codec.

Works on Zen as well.

That’s an interesting speculation, but I’m inclined to believe their official reasoning. (That being they just didn’t really care about the format and/or went with whatever Chrome said at first. A year or so later they changed their mind and said they wanted an implementation in a memory-safe language, which prompted the JXL team to work on it.)

Which makes sense as Orion uses the same engine as Safari.