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.
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)?
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.
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.
[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.
The bees and reindeer visiting my web site will be very happy to see UV images.