Shipping JPEG XL in Chrome
developer.chrome.com
developer.chrome.com
While AVIF may have a slight edge in some cases like in fairly lossy compression, you won't really go _wrong_ with JPEG XL (unless strongly CPU constrained) and I think the strength of the format is its extreme versatility as a "be all end all image format" for some time where comparative performance depending on functionality ranges from respectable to excellent. It can work as a replacement for AVIF, PNG, JPEG, WebP, even certain TIFF required scenarios (high bit depth, multichannel, layers) depending on use cases.
PNG/JPEG have strong support (nearly everywhere). I think of them almost as the modern TIFF - relatively simple, and almost everything supports one or both of them (few to no issues).
JXL may eventually get there (that indeed seems to be its goal), but for now I wouldn't drop e.g. PNG or JPEG support in favor of JXL now.
And arguably, perhaps never drop support; its such a prevalent format, even if all software (prevalent or otherwise) supports the format in 10 years, there will be such a huge stockpile of JPEG/PNG that something will need to be used to read/convert.
TIFF is not simple at all. There is a joke that it stands for “Thousands of Incompatible File Formats”.
In the GIS world we have a Cloud Optimized Geo Tiff. It is almost a standard now. This better than go to another format like Jpeg2k or ECW.
Tiff is an extendable format. Bit I am not saying that it can be better than JpegXL. Just a curiosity.
Even if JXL is superior in every single way, it doesn't make sense to throw out a perfectly functional graphics package and design language for a marginal bump in capability.
For me now, its marginal.
For a past customer, not at all. That customer really cared about delivering image-heavy pages quickly. There was a fairly big difference in customer perception at a timing threshold.
The bees and reindeer visiting my web site will be very happy to see UV images.
WebP and AVIF and HEIC had similar advantages but also some disadvantages (honestly chief disadvantage to WebP in my humble opinion was that nothing except web browsers -- to this day -- seem to support it!).
Another important point in its favor is that JPEG XL is designed as a royalty‑free, open standard, and Google provides a perpetual, worldwide, royalty‑free patent license for its reference implementation.
Avoiding JXL (once the rollout is sufficiently complete) seems, to me, like still shipping (non-animated) .GIF files where .PNG is better and smaller.
Things in these categories have colorful packaging with spot colors, metallic inks, coatings, as well as store displays with carefully designed lighting. The added cost is justified because it increases sales. It makes sense to carry that over online.
Even if it cannot, getting the same quality as 'classic' JPEG in fewer bits is still useful. So you have:
* better quality in the same number of bits
* same quality in fewer bits
But I’m sure there are some that will say 64k of RAM is all anyone will ever need!
The cost of HDR displays is decreasing, and the data cost is minimal. (adding more bits to video actually decreases the size because the rounding errors get smaller)
Yes.
JPEG can represent "X" number of colours, but the human eye can detect Y>X colours. JPEG-XL can represent >X colours (but not as many as they human eye, Y):
* https://en.wikipedia.org/wiki/Wide_color_gamut
* https://en.wikipedia.org/wiki/JPEG_XL#Versatile_and_future-p...
It's trivial to make an image that you can see the 8-bit quantization in. Just make 256 vertical gray bars, equally spaced. In much of the image (usually the darker parts, but depends somewhat on monitor calibration) you will see the border between two values. Note that this is every single possible grey value in 8-bit RGB, so it is a proper un-dithered rendering of a gradient, and the borders you are seeing are definitely quantization artifacts.
Now, if you apply proper dithering, particularly on a high-dpi screen, you can make it look a lot better, possibly even undetectable.
And this is just with the dynamic range that is comfortable on a computer monitor! If we really want to represent vibrant images, then the glare of the sun off of shiny objects should be much brighter than the "paper white" background used in e.g. your word processor. It should be intuitive that the brightest highlight in a real-world image ought to be too uncomfortable to fill your entire monitor with...
Lastly, there's a question what and how the image gets to the browser. Sure for the images on the landing page for $LARGE_CORPORATION you have a graphic designer make everything look great, and since most people still have 8-bit displays, you'll want something that looks good on one. But what about e.g. a site for uploading photos? Are you going to quantize all of their photos before displaying them (possibly to someone with an HDR display)?
[0]: https://github.com/dropbox/lepton And Lepton is dead.
JPEG XL is marketed as a high end format for photographers and already has support in most editing software.
Meanwhile, there's a lot of modern music that takes full advantage of quality gear, but is basically unlistenable on bad speakers.
There's nothing wrong with either approach, but if you're not trying to raise the bar why not just stick with the lowest common denominator?
Dean Martin recorded his records to sound good on low-end tween girl 1960's record players. My wife has one, and his stuff sounds great on it.
My wife also has two very high-end modern record players. Dean's old records sound like crap on that.
Master the media for the method.
Which I think it might be one of the reasons why Instagram still uses JPG for their images. The rule of thumb is that if your product is picture quality sensitive (like photos in IG) then use JPG, if not then WebP is fine since the compression is higher.
As a test, I have a set of 36 old MS paint Drawings, originally drawn on Windows 98SE, originally saved in bitmap format with a total size of 53.4 MB.
Transcoded to PNG format using FFmpeg and the highest -compression_level of 100, this same set of images takes up 403.8 kB.
Transcoded to -lossless WebP format using FFmpeg and libwebp with the maximum -quality value of 100 and maximum -compression_level of 6, the set of images takes up 174.8 kB.
Transcoded to lossless JPEG XL format using cjxl in the highest compression settings, the 36 images only takes up 126.6 kB.
Given the computing power required to decode JPEG XL images and their limited support, it may not make sense to use JPEG XL for non-archival purposes, but lossless WebP is an excellent middle-ground, achieving over 2x the compression level of PNG.
Lossless WebP has also been supported by all major web browsers since September 2022, when Apple finally added full support for lossless and animated WebP images. It really doesn't make sense to still be using PNG, unless you're targeting really out-of-date Mac or iOS devices. Having drawings and illustrations be 50% smaller (versus PNG) is huge!
I was left feeling like the next time we adopt a format that tries to do everything, it should actually do everything just as well or better than its predecessors. Lo and behold, JPEG XL is probably the first format which actually achieves this, covering all kinds of pictures you can think of and doing a pretty good job on all of them. So for the first time, I feel like the format has actually earned its place in the ecosystem, rather than just being some megacorporation’s personal favourite.
Of course, this point of view is emotional more than rational. Technically, WebP is a sensible choice, so I don’t mean to discourage anyone from using it today.
How so? This table [1] shows the adoption dates for WebP in various popular programs (as does Wikipedia [2]). Of all high-profile programs, Chrome was the only early adopter; other browsers were avoiding it for years, not to mention off-line software. Mozilla went as far as to work on a JPEG encoder [3] after WebP was introduced by Google, to see if maybe JPEG itself could be improved enough. How does that not read like one company’s choice and push?
> Almost everyone wins when bandwidth is cut and you get higher quality for less space.
Sure, but that doesn’t mean you immediately adopt every new codec that brings improvements in some area. With every new feature comes new code, new baggage, new potential attack surface. You have to ask if the improvements are big and consistent enough to go through the effort and burden the entire ecosystem with yet another format everyone now has to deal with. You need to think of the user and developer experience both in and outside of the web.
Microsoft would have been perfectly within their right to blame the format, since Google just decided to let it run wild on the web without garnering more support for it first. The format has its pros and cons, and it’s up to all the involved parties to weigh them and hopefully reach a consensus.
[1]: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong_strong_timing_and_interoperability
[2]: https://en.wikipedia.org/wiki/WebP#Support
[3]: https://research.mozilla.org/2014/03/05/introducing-the-mozjpeg-project/If you're saying they did a thing where 200KB webp had an advantage over 200KB jpeg, please link your source. When I search I only see people saying that's not the case.
https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YM...
"We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox. So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox."
Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]
In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]
It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.
There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.
[1]: https://issues.chromium.org/issues/40168998#comment85
[2]: https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985
[3]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287
[4]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1811972676
[5]: https://github.com/mozilla/standards-positions/pull/1064
[6]: https://github.com/libjxl/jxl-rs/graphs/contributors?from=03%2F01%2F2024&to=01%2F01%2F2026The way I read it, both companies were tentatively interested until Google said they changed their mind, and shortly after Mozilla decided they didn’t really care. Correlation doesn’t imply causality, but their positions followed a somewhat similar trajectory at the very least. (In contrast with, say, Apple.)
I just don’t see where you keep getting the idea that Google was at some point far more supportive of JPEG XL adoption than Mozilla was.
We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)
Why? AV1 was developed as a video codec. That doesn’t imply it’s as good of an image format nor that everyone who supported its development has vested interest in making it into one. Just because someone has made a cool hammer doesn’t imply they now need to view everything as nails. (This provenance even brings some drawbacks with it, yet this time seemingly no one took a pause before tossing in yet another image format.)
> Their hope was to use the existence of AVIF as leverage to give hardware vendors more incentive to provide hardware support for AV1.
This is the first time I’m reading about this and I’m having a hard time seeing how decoding images would make for a significant incentive to provide hardware support (especially when everyone was already more or less on board with AV1 as a video codec). But I could be wrong, of course. If you can provide any links where Mozilla gives this reason for adopting AVIF or any hardware vendor gives significant consideration to decoding AVIF in hardware, it would be much appreciated.
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'm assuming that for more persistent, cachable types of images, there wouldn't likely be that type of problem, right?
It's more if you accept image uploads from users in any way. I experienced a ~10-20x increase in processing time when accepting AVIF images, and I found that I couldn't rely on sync functions for that. I had to both change to async and upgrade hardware in order to support it at scale. I run a small reddit-like site that accepts media uploads and the end result was I had to choose between unshipping AVIF or doubling my server costs. I found that the image savings over webp weren't worth it at the time.
The same story is likely true for JXL until there's hardware encoding.
We tried AVIF and file sizes were much better but it would take multiple minutes just to generate. We also got feedback from our self-hosted customers that it was using way too many of their system resources.
So we’re now using WebP which generates in about 10 secs using much less CPU. I’m open to JPEG XL if it can improve on those metrics.
On the other side we introduce yet another format that has to be supported, that creates compatibility issues with people that is using older browsers, or older software, older cameras, etc.
It's just another format meant to replace other formats to uniform all, so now we have N+1 formats that the user has to deal with.
What are the benefit for the final user? A reduction in 50% of the image size? We are not talking about videos (I re-encoded a lot of older videos to h265 because it save me almost 100/150% of the space, but unless you are a professional photographer, that btw uses raw format for archival, you don't have Tb of images so the saving for the average user are neglectable!).
Many that you can search the web for, but to address the specific points you mentioned off the top of my head:
- Lower cell data usage for users
- Not everyone has gigabit fiber
Second, the "all connections are fast, what's the point" is one reason why the web is so slow. Connections are often slower than the dev with his 1gbps connect feels every day. The average website loads slower (in wall clock time) than it did 15 years ago. Smaller files and fewer network round trips would do everybody a favor.
This strongly depends on where your domicile is, even in Europe and the US. And lot of the users live outside these areas.
> JPEG was fine in the days we had much slower connections
Except that waiting for a large picture to load was very much thing, and in many cases still is.
> What are the benefit for the final user?
A number of users are still on metered mobile plans, and have little storage on their phones. With the current situation in electronics production, new phones are not going to offer more space, cheaper; to the contrary.
Also, publishing larger / better quality images becomes easier and cheaper.
The case against JPEG XL https://giannirosato.com/blog/post/case-against-jxl/
There are some unanswered questions about the methodology used, the resources spent on development of the respective encoders is not taken into consideration, the future developments of JPEG XL encoding are written off as too costly and the author’s opinion on what kind of content is appropriate for the web is quite subjective. See also the recent discussion:
* The versatility is a bit of a downside when it comes to lossless. Programs play games when it comes to formats mixing both and when may appear to be lossless isn't always thus. It would have been nicer if there was a direct way (via extension+mime) to indicate lossless is expected.
* JPEG transcoding is a very nice feature.
The problem is that it's not necessarily trivial to tell programs/pipelines/transforms to act only losslessly (there's definitely no common switch; Quality 100 is in fact still lossy in some encoders/formats). In practice some programs use the extension to realize what they should be doing.
I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot.
https://security.snyk.io/vuln/?search=libjxl
I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.
https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...
right?
While I'm happy for the reversal, it would be helpful to have a corresponding explanation addressing what changed leading to this reversal just two years later (assuming the decision to support was made 9-12 mos ago). Since significant decisions are usually harder to make in big companies (due to many competing prioritities, stakeholders, and processes), they tend to also be harder to reverse (especially in just two years, when most of original deciders are still in the same roles). I suspect the real thing that changed is more interesting than "the technology or people changed" or "our prior assessment was wrong".
Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.
Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.
Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.
A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.
I'm on the other side, I hate webp because if I download such an image a lot of apps don't support it. So typically I need to screenshot it instead to get a usable jpg/png.
Now one more format to hate.
I would say webp/jxl/avif is anti-general compute, since they require very recent software.
I know that end-users making memes or whatever aren't a demographic that will matter for adoption, but it seems really weird that this is still a problem on Windows and Mac in 2026. I've searched for browser extensions to no avail.
I just tried it out now, using Waterfox on macOS 27. The save image dialog literally already has a Format dropdown. But I'm guessing it's just a weird part of some native dialog, it lets me select between "WebP Image" and "All Files". This kind of design could've been used to allow the user to save it as a different format than what it was served as.
If you have support for multiple file types, you're already using multiple libraries or you're using a library that handles several kinds of file, either way you can and should update that.
Imagine if installing libzstd meant that every program on your computer suddenly knew how to use ZSTD compression, or adding libjpegxl added support to every browser, word processor, and age editor you’d already installed.
Some parts of AmigaOS were wonky, like lack of memory protection. Others would still be phenomenally useful today.
Removed because no one from Google benifits from supporting it then.
Re-added because someone could get a promotion by supporting it now.
Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?
They always abandon shit like this.
Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.
Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.
Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.
How many man-hour effort does it take to create jxl-rs ?
Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.
I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
~$ du -h $(which dd)
76K /usr/bin/dd
$ du -h $(which pv)
116K /usr/bin/pv
sudo pv -Yo /dev/blah /path/to/your/image.img
My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)
Another example clown app: the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB. Derp.
MacOS used to include Java out of the box, and then they stopped doing that. How else should an app reasonably behave to keep supporting new versions of the system?
What you're saying is it's the ideal kind of application for not obsessing over its background resource consumption, given that it's only going to be running for 10 minutes once or twice a year.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library
I got my A1000 in late '85 and only had prior exposure to 8-bit home computers (C64, Atari, etc), CP/M and DOS (no mainframes, minis or workstations). I didn't actually use Macs or early Windows until the early 90s and it was shocking how backward they still seemed in some ways. I'd sort of the assumed the other major platforms were making similar advancements throughout by the late 80s and shocked to find out how wrong I was. It wasn't until the mid-90s that PCs and Macs felt like they mostly caught up on QoL and OS features.
Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.
I have a feeling now JXL is here to stay, finally.
More likely the Google eng. director who tried to get rid of it because of not-invented-here syndrome (it was built in a different org) got a new job or changed company.
I have to think this is a substantial reason for the backflip here as adding a new huge C library to browsers is a huge concern.
Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940
JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208
Chrome Jpegxl Issue Reopened - https://news.ycombinator.com/item?id=46033330
The case agains JPEG XL - https://news.ycombinator.com/item?id=49690554
The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well.
Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.
Discord Mobile absolutely supports animated WebP (in fact I just tried uploading one to make sure I wasn't hallucinating here).
The non-exhaustive table linked below shows how long it took for different programs to support different image formats since their introduction. Outside of Chrome, Chrome in disguise, and whatever has become of Firefox, adoption of JPEG XL has been far more enthusiastic than it ever has for WebP—or AVIF, for that matter. So we are very unlikely to have a long period when JPEG XL only works on the web and nowhere else.
https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...
This is pretty wild. Google can't align their own tools for it?
Seems like terrible branding if it wants to be taken seriously as a standard.
Personally I fully expect jxl to succeed where avif failed and webp floundered.
Nothing wrong with that per se, it's just old and limited, especially compared to avif/AV1 which would be like a theoretical VP10 at this point.
And much (though not all) of its improved compression (before it damages the image too badly) was anyway matched by the better JPEG encoders which were released and improved over time. It sure benched very well against a 30+ year old JPEG encoder implementation though.
JXL has a pixel-accurate JPEG-input mode with no generation loss which already beats WebP, a native mode which is way way better even, it addresses many more use cases and is not Google's pet project (saying this while thanking them for all the foundational work from which modern image/video codecs benefit - JXL itself first and foremost!) so it DOES have better than a snowball's chance in hell of becoming the defacto standard of the next 10-30 years and we'll soon see it in silicon.
So yeah.
The REAL reason for WebP hate:
Google started converting image results to WebP automatically. Absolutely, officially diagnosed, mentally deficient move. Having every kid download a image of google and be unable to send it to discord made an ARMY of people who call it the "bad poopoo cringe format for <slur>s"
1. Lossy: AVIF is vastly more efficient at any fidelity target with reasonably modern encoders (libaom, SVT-AV1). Even proprietary WebP encoders are more efficient than libjxl. More efficient meaning better quality at the same size. This is provable even beyond modern metrics.
2. Lossless: JPEG XL is ~10-13% better than WebP here, but can be >6x slower to decode. What is the point of saving 10% bits when the client pays for it? There are lossless codecs more efficient than both that are faster to decode than both, too.
3. JPEG Recompression: Same deal, the increased decode time often erases the time-to-display gains (even on modern devices) - not just me either, this was proved empirically in the previous HN thread on a Pixel 9 Pro.
4. AVIF can have as many progressive decode passes as you like, and they aren't just "layers", they actually work together.
There are strengths, like 32-bit float precision and support for a lot of layers. I'm just lost on what the criteria for including a new codec in the Web is at this point. Google was heavily involved in JXL's development so I understand their incentives exist, and the "all-in-one" codec argument, but other than that, I'm a bit lost.
"I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.... [JPEG XL] is meant to be everything to everyone... Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere"
Browsers aren't trying to be narrowly scoped anymore, nor made just for the web (Rust and LLMs must have improved their confidence regarding security). Other usecases (like PDFs and cameras) clearly benefit from JPEG XL. Once support was added, it was easy to just turn on for the web. After all, they need to consider the opposite case where someone creates a jxl image and tries to upload it to the Internet. They might even think that having a format that is everything to everyone is useful and eventually the (en)decorders will improve.
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
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.
The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.
For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.
I have not read that many direct comparisons here.
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).
The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.
Where do people get this stuff?
Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.
Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.
WebP is ubiquitous now, not the case in 2010 when it was released.
It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.
Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.
That's wrong, you declare this with an ICC profile, done.
Lossy WebP has an important limitation in being YUV 4:2:0. And it's strictly 8-bit. That is the actual reason it doesn't replace JPEG, which is rarely even implemented to a greater extent.
Lossless WebP replaces GIF. Despite much better compression, it doesn't replace PNG, which supports 16 bits, and has stronger metadata support.
When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.
> you just truncate the output stream at the right proportion of pixel data
Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.
If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.
This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.
Oh, they finally ratified that? Excellent. This is news to me. You have a link?
Loading vs loaded difference needs to be clear.
It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.
png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.
I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.
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.
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...
But it makes so much sense for Apple, Mozilla, and Google to support jxl-rs. Of course, that doesn't mean it's going to happen.
Keeping quiet and then adding jxl-rs to a dot release like Safari 27.4 or something is also a very Apple thing to do.
TBH, this one is just a terrible technical decision that Telegram made ages ago ("we use WEBP to represent stickers, therefore all WEBPs are stickers"). It's not the only weird file-format decision they made; see also "all short MP4 videos with no audio are actually GIFs". :)
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
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
(You know... for "Wumbo")
Does the one at the end of .JXL count toward the total? Nobody knows what it stands for anyway.
But people are definitely going to assume "eXtra Large". Lots of people. I guess a few will think "excel" (as in JPEG XL comes out ahead and is superior).
---
Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".
I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd
JPEG artifacts are literally a meme, normal people are aware of this stuff.
I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.
But it's also a valid point.
If you reencode a jpeg to a png, you used a lossless format but your image is very lossy.
My guess: the engineers didn’t win the argument. 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.
why? is it a particular apple flavor and not an actual standard?
As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.
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.
Google and Mozilla executives. The 'why' is not public knowledge. Maybe someone has a personal vendetta against some people involved in jxl.
Sadly, still far from adoptable today's web: https://caniuse.com/jpegxl = 17% https://caniuse.com/?search=webp = 97%
Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Are you saying that the percent it'll be in six months isn't relevant to you, or something? You'll probably be working on most of the same projects, even. If you do care about the future then yes caniuse is missing that point.
> Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Once a few more versions of chrome roll through it'll jump up to almost 80%, and you can have a fallback easily.
It absolutely is relevant.. but only in about 6 months :)
Suppose the obvious case, i have some resizing pipeline for images. Would i include support today in my resizing pipeline today and pay a few extra cycles and storage for someone that my clients can't read?
It would be cool to have a subscribed alert for when the tech crosses a certain % threshold adoption so i can look at it again, otherwise it just relies on my brain's flawed long term cron job
Yes, this is literally what the <picture> element is for.
Your hypothetical pipeline would be able to convert <img> elements into <picture> elements with multiple <source> elements for different user resolutions and format supports.
I’ll see myself out.
This had a cascading effect, where we immediately (within hours) dropped support for jpegxl on Pixel Camera and various other Google products
But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date:
Not to be a downer — it's one necessary step on the road.
Have to stick with AVIF which supports up to 12 bits.
Seems to be between a little and a lot faster in almost all of the tests.
For that tool you need to output an uncompressed target and use the reference command line tools, preferably libjxl and cjxl (which is still the reference, while jxl-rs remains the experimental), to create the JXL. You will have better compression with better quality, minus the glitches.
The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png.
With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.
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.)
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.
And lossless jpeg-xl exceeds your idea
One to embody power, the other one to crave it?
I'm confused about the connection.
What counts as a “safety mechanism”?
https://chromium.googlesource.com/chromium/src/+/main/docs/s...
If you use a safe language like Rust, you can afford untrusted input and no sandboxing.
If you use an unsafe language such as C++, you must chose between trusted inputs or sandboxing.
I was curious as to where rfgplk's implementation lay within the Venn diagram.
> you can afford untrusted input and no sandboxing.
I would not trust a rust program un-sandboxed! There are security bugs in rust itself.
Your llm has JPEG xl programs in the training data. You copied from GitHub.
Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs.
Fuck HDR or at the very least give people an option to turn it off!
If you're using a mobile browser without extension support, you should tell the devs of it to work on that.
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.
50 times smaller than JPEG 2000.
AVIF is still better at 1 bit per pixel and less. (JPEGXL is more efficient at more than that.) Is it possible for JPEGXL to beat that?
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.
Folks, it's just a tool