Rollout looks solid, but I'll probably avoid deploying it to anything live til early next year at the minimum. That'll give time for browser adoption to happen.

Biggest concern I have was the same I had with AVIF a couple years ago, which is hardware acceleration on the server side. I attempted to roll out AVIF only to find out the encoding time was so long that sync calls were timing out due to queuing. It's gotten a lot better, but just know that all of these newer formats really do need more compute. It may not be worth the cost tradeoff vs webp until encoders are baked into chips.

I don't see any advantage of any of the new formats over the good old and proven formats, so I stick with PNG and JPEG (properly optimized.) I can fire up any old browser and it will just work.

Seems Firefox will get support in version 158

https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YM...

Being an “everything” image format sounds awful and something that’s over engineered and no person understands it.

Yes I think the major story here is Google removing and then re-adding it back. Big companies have big egos, so this is quite a miracle.

I have a feeling now JXL is here to stay, finally.

Wasn't it due to poor security? libjxl had notorious bugs that would've on par with webp exploit, if present in browser:

https://security.snyk.io/vuln/?search=libjxl

I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.

Why do browsers need to support every media format? Why can't it be shipped as a shared library for the whole system to use?

> removed a while ago and them seemingly not being interested in supporting it

Removed because no one from Google benifits from supporting it then.

Re-added because someone could get a promotion by supporting it now.

What issue do people have with webp?

JPEG-XL is not particularly patent-laden and its license is correct for the use-case.

Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.

It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.

And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)

iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).

> MacOS can take a long time to update with support for new formats.

Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].

When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.

[1]: https://webkit.org/blog/14445/webkit-features-in-safari-17-0...

[2]: "iPhone 17 Pro’s Camera Leap: JPEG‑XL, Cleaner Shots, and Pro Filmmaking Tools" - https://modernengineeringmarvels.com/2025/09/19/iphone-17-pr...

True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.

Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.

It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.

The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.

Ugh. Every time I accidentally put a HEIC on my Windows machine, or one of my students tries to upload a WEBP to our school's LMS :/

If I remember correctly Instagram didn't support WebP either.

You can’t really do that with PNG today either, because of all the PNG optimizers that quantize images before encoding them to PNG for better compression.

That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.

This is something that can be addressed by file managers - showing a metadata entry on whether it's lossy or lossless. File extension (along with the bifurcated mainstream adoption of JPEG and PNG) has been a great proxy to do this, but like others noted, can be deceptive, which is arguably worse.

You cannot tell it just from the extension either. If you like extensions, you can use a '.lossless.jxl'. And in general for most formats, you can use metadata to store that info (also doesn't guarantee anything)

This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.

ah, that's a good point.

perhaps use .ll.jxl to indicate "lossless jpegxl" informally?

prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter

I can't really think of a scenario where that would be useful? File-size is more indicative of quality anyway.

Art sites get the biggest gain with JXL. They can losslessly repackage every single JPEG uploads they have for practically zero cost. Existing PNG can also be losslessly compressed to JXL too, and just wrapping JXL around PNG yields improved compression (Note for last part: it is still in proposal status)

> The executives just gave up once all the other browsers had added support.

The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.

It's interesting how different theories come about when there is a lack of information and a high degree of preexisting bias. Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format. However as industry adoption increased and a newer safe library appeared, the decision was changed. Also, note that while Google developed the new rust library, it wasn't the chrome team who made the investment.

That's... not what happened? See the timeline I posted here: https://news.ycombinator.com/item?id=49445897

JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't.

My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle

I think it might have something to do with a Rust based decoder becoming available. IIRC one of the reasons for not implementing it before was expanding the attack surface.

They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027

I thought the reasoning was Google wanted to cartel their own fledgling webp format and didn't want to promote competition?

Here's a benchmark over time of jxl-rs (Rust) vs libjxl (C++) across both memory usage and performance: https://jxl-rs-perf.lucaversari.it/. I'm inclined to trust that it's a decent benchmark since it's from Luca Versari, a key person in the original JPEG XL standardization effort and development of libjxl, and is now the main developer of jxl-rs.

Seems to be between a little and a lot faster in almost all of the tests.

I have a feeling that progressive loaders got downgraded along the way for whatever reason. I remember seeing progressive JPEGs and PNGs also load... progressively. JPEG even often had a grayscale-like first layer.

I believe it's been available in Firefox for a while now, just behind a feature flag

Next up: Phones and cameras. It would be so great to have a common image format again after years of fragmentation.

I doubt anyone that wants to keep their job in big tech would ever publish something like that.

So do you think your implementation is better? Or there are finer parts of the spec it’s missing?

Your llm has JPEG xl programs in the training data. You copied from GitHub.

Does it satisfy the rule of two?

No, JPEG XL is an open standard.

Both JPEG XL and WebP far exceed AVIF when it comes to lossless. For lossy, AVIF used to do better at low quality and JPEG XL at high quality. But apparently AV1 encoders have improved a lot since then, closing the distance. An article comparing the two was posted recently:

https://news.ycombinator.com/item?id=49690554

The author, who has worked on said AV1 encoders, has expressed doubt that JPEG XL encoders could improve much with only reasonable amounts of effort, but that was also only their personal (if educated) guess. With JPEG XL finally seeing adoption on the web, we will hopefully see work on the reference encoder resume in earnest soon.

So for now, I’d say you’re fine with AVIF. Unless you’re doing lossless, because AVIF sucks at lossless. (And JPEG XL has the unique feature of supporting lossless JPEG transcoding, too.)

You can’t just ignore signal compression algorithms unless you are fine allocating 4-5x more bandwidth to images.

>without the weirdness of PNG 'line based loading' which is obsolete nowdays

How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.

I believe 7zip outdoes bzip2 these days along every metric

And lossless jpeg-xl exceeds your idea

These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).

What would be a better name?

What's wrong with JPEG 40?

50 times smaller than JPEG 2000.

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

I will say windows implementation of HDR - at least the way Chrome handles it within Windows is somewhat of an abomination - so I'm sure Apple's iOS is just as poor!

but sometimes it's not HDRs fault - it's just the segura effect. People with cameras exceeding their capability levels, not understanding what you need to do after you shoot video in LOG.

I mix multi-monitor some-HDR some-SDR in Windows, it's bad.

I do not know if JPEG XL is competitive with AVIF for very compressed images, because that is mostly a concern for those who want to host at a minimum cost Web pages with embedded images. I assume that AVIF must be better for that purpose.

On the other hand, AVIF cannot compete with JPEG XL for high-quality photographs, which is something much more important for me, because it is a format suitable for storing my own photographs and it is a format that would make me appreciate positively a Web site that would have beautiful images in this format.

That isn’t my experience. I tried compressing conference proceedings into thumbnails with tiny file size and for this purpose I found that JPEGXL is far better than AVIF

is that a bad thing?