alt.hn

1/21/2026 at 4:38:26 PM

JPEG XL Test Page

 https://tildeweb.nl/~michiel/jxl/

by roywashere

1/21/2026 at 8:51:46 PM

Starting from v145 Chrome supports JXL.

There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...

by senfiaj

1/21/2026 at 10:17:08 PM

And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/

by pkulak

1/22/2026 at 9:44:06 AM

Wonderful. Allow an "unmonitored" extension from a random stranger on the Internet have access to "all data for all websites" just to support an image format for which Mozilla should have long built in native support...

by Santosh83

1/22/2026 at 11:19:29 AM

Security concerns are exactly the reason the format doesn't have native support yet. However: https://github.com/mozilla/standards-positions/pull/1064

by Vinnl

1/22/2026 at 1:31:28 PM

That's not the reason, but the excuse. The reason Firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.

Also the parent comment was about that you really shouldn't just let a random Russian guy run any javascript on any website you visit, that's stupid.

Also also, am I missing something, or Firefox extensions are broken, there is no way to limit an extension to websites (allow or disallow), or even just to check the source code of an extension?

by bmacho

1/25/2026 at 4:12:59 PM

The link I posted shows that Jpeg-XL will come to Firefox, and that that same Google is the one making that possible by writing a secure implementation.

by Vinnl

1/22/2026 at 1:38:54 PM

> That's not the reason, but the excuse. The reason firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.

So what, you think they were just lying when they said that they'll ship JXL when it has a Rust implementation? You think Mozilla devs were just bluffing when they were working directly with the JXL devs over the last year to make sure everything would work right?

by lonjil

1/22/2026 at 2:00:50 PM

No, I don't think they can withhold support if it's a no-brainer to support it. But they also tried everything they could to not support it.

by bmacho

1/23/2026 at 6:37:12 PM

This...

I would not install non-recommended Firefox addons for things that can be achieved in about:config.

Just do set image.jxl.enabled flag in about:config to true.

by mikae1

1/22/2026 at 1:52:00 PM

Firefox Nightly v149 has added experimental support via Settings > Firefox Labs:

  Webpage Display
  Media: JPEG XL
  With this feature enabled, Nightly supports the JPEG XL (JXL) format. This is an enhanced image file format that supports lossless transition from traditional JPEG files. See bug 1539075 for more details.

by iam-TJ

1/22/2026 at 8:23:23 AM

It's a good use case for WebAssembly. For browsers that don't yet support JPEG XL natively the page could provide a wasm decoder.

Like this demo page: https://bevara.github.io/Showcase/libjxl/

by breve

1/22/2026 at 8:43:09 AM

I published some benchmarks recently:

https://op111.net/posts/2025/10/png-and-modern-formats-lossl...

I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)

by demetris

1/22/2026 at 2:26:36 PM

It seems like the natural categories are (1) photographs of real things, (2) line art, (3) illustrator images, (4) text content (eg, from a scanned document).

Is there a reason you used only synthetic images, ie, nothing from group 1?

by tasty_freeze

1/22/2026 at 3:58:59 PM

Hey, tasty_freeze!

The motivation behind the benchmarks was to understand what are the options today for optimizing the types of image we use PNG for, so I used the same set of images I had used previously in a comparison of PNG optimizers.

The reason the set does not have photographs: PNG is not good at photographs. It was not designed for that type of image.

Even so, the set could do with a bit more variety, so I want to add a few more images.

by demetris

1/22/2026 at 10:12:14 AM

Would be nice to also see decompression speed and maybe a photo as a bonus round.

by enimodas

1/22/2026 at 12:11:07 PM

Yeah.

Numbers for decompression speed is one of the two things I want to add.

The other is a few more images, for more variety.

by demetris

1/22/2026 at 4:58:02 PM

Max memory required during decompression is also important. Thanks for sharing this research.

by tedd4u

1/21/2026 at 10:43:06 PM

One thing I like about JPEG-XL is that it supports all kinds of weird image formats.

For example, I used to work with depth data a lot, which is best expressed as monochrome 16-bit floating point images. Previously, TIFF was the only format that supported this. Many shops would instead save depth images as UINT16 .PNG files, where the raw pixel intensity maps to the camera distance in mm. The problem with this is that pixels more than 65.535 meters away aren't representable. (Hot take: I personally think this is one reason why nobody studies depth estimation for outdoor scenes.)

JPEG-XL supports more weird combinations here, e.g. storing greyscale float32 images (with alpha even! you can store sparse depth maps without needing a separate mask!)

It's like, uniquely suited to these sorts of 3D scene understanding challenges and I really hope people adopt the format for more scientific applications.

by gcr

1/22/2026 at 11:14:23 AM

> One thing I like about JPEG-XL is that it supports all kinds of weird image formats.

And it is probably the reason why browser vendors disliked it. Lots of complexity, it means a big library, which is high maintenance with a big attack surface. By comparison, webp is "free" if you have webm, as webp is essentially a single frame video.

by GuB-42

1/22/2026 at 7:12:23 PM

AFAIK browsers do not reuse any VP8 codepath for WebP, they just use libwebp, which decodes lossy images in software. WebP has a non-VP8 lossless mode too. The concern about image format attack surface is also probably because of the recent exploit in libwebp.

by edflsafoiewq

1/22/2026 at 9:17:45 AM

On the subject of tiff, why is it not used more? I mean, it is more or less really a container format right. Why are we not using it all over the place but with modern compression methods?

by somat

1/22/2026 at 1:31:48 PM

It is used quite a bit.

As just one of innumerable examples, it's the basis for Adobe's DNG raw photo format and many proprietary raw formats used by camera manufacturers (Nikon NEF, Canon CRW and CR2, etc.).

Speaking as an outside observer, the ISO Base Media File Format seems to have more mindshare for newer applications, presumably on account of its broader scope and cleaner design.

by jasomill

1/22/2026 at 12:53:00 AM

There is also FITS, but that is mainly for astronomical applications (and is in general an insane and terrible format). But it supports tons of types!

by JBorrow

1/21/2026 at 4:55:01 PM

Orion, and presumably other Webkit-based browsers that are actually up-to-date, can also see the image.

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

by p_ing

1/21/2026 at 5:36:56 PM

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 :(

by nine_k

1/21/2026 at 6:01:52 PM

> 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?

by RicoElectrico

1/21/2026 at 10:16:03 PM

Designers might also be hesitant to use an untested file format for print, too.

If there’s a large amount of paper that’s been purchased for a job, I definitely wouldn’t want to be the one who’s responsible for using JPEG XL and – for whatever reason – something going wrong.

Pixels are cheaper than paper or other physical media :)

by sanjit

1/21/2026 at 7:50:30 PM

Yes, because those systems cost gobs of money. You don't replace them just for the hot new thing.

by p_ing

1/21/2026 at 11:41:58 PM

Replace? Why bring that up?

The company that owns whatever system can and should be able to convert formats.

by Dylan16807

1/22/2026 at 1:36:06 AM

They request formats that their equipment handles. They're not in the business of converting a user's file type from one to another. That would be inconsistent from what the user sent.

Here's who I order from, you can see the particulars of what they request.

https://support.bayphoto.com/hc/en-us/articles/4026658357979...

by p_ing

1/22/2026 at 6:51:43 AM

> They're not in the business of converting a user's file type from one to another.

Their job is getting an image file into reality, not to be the absent owner of a big machine.

> That would be inconsistent from what the user sent.

If the machine accepts some type of normal image file, then they can losslessly convert other file formats to that type. There is nothing inconsistent about that.

by Dylan16807

1/22/2026 at 1:40:47 PM

You're free to make such assumptions.

by p_ing

1/22/2026 at 3:49:08 PM

What are you calling an assumption?

My first statement is an opinion/judgement, not an assumption.

I'm confident my second statement is true. Note that any argument that says niche formats are a problem because color space might be ambiguous also applies to the formats they do accept.

by Dylan16807

1/25/2026 at 8:12:29 AM

Who should accept responsibility when a conversion is not as expected?

There are very few ‘lossless” conversions possible if you consider the loss of a data or metadata could affect the result. So if printer did accept a file that needed to be converted, and then during printing and converting they found conversion could lead to unexpected results should they cancel the print run? There is just too much to go wrong in printing already without these extra problems.

The print industry has a long and storied history, and for whatever set of reasons, printers only accept very specific profiles of specific formats.

by diroussel

1/26/2026 at 9:48:38 PM

> Who should accept responsibility when a conversion is not as expected?

Who does it already? The system already takes files that could have unexpected results.

It's likely that if they took some other reasonable file types while always pre-converting they could actually reduce the error rate.

by Dylan16807

1/21/2026 at 10:22:32 PM

Yup, Gnome Web loads it just fine! Man, it really is a great browser. I try to switch to it every 6 months, but then I remember that it doesn't support extensions at all. I could give up everything, but not 1Password. Nothing is worth copy/pasting credentials and losing passkeys entirely.

by pkulak

1/22/2026 at 1:45:42 AM

Have you tried KeePassXL with SyncThing? I've heard good things about that setup.

by encrypted_bird

1/22/2026 at 9:26:28 AM

For what purpose? While it's a perfectly good password manager, when used with Gnome Web it also means copy/pasting passwords and losing passkeys. Doesn't it?

by Dylan16807

1/22/2026 at 10:45:17 PM

When I commented that, I did not realize Gnome Web was a web browser (I'd never heard of it frankly), let alone a non-Firefox-based browser. Lol.

by encrypted_bird

1/21/2026 at 7:50:01 PM

I'm seeing the image on zen which is a firefox fork but not on firefox itself :/

even with `image.jxl.enabled` I don't see it on firefox

by numbers

1/21/2026 at 8:02:47 PM

Checking the Firefox bugs on this, it seems they decided to replace the C++ libjxl with a rust version which is a WIP, to address security concerns with the implementation. All this started a few months ago.

Maybe the zen fork is a bit older and still using the C++ one?

by capitainenemo

1/21/2026 at 9:19:22 PM

... update. after reading the comments in the rust migration security bug, I saw they mentioned "only building in nightly for now"

I grabbed the nightly firefox, flipped the jxl switch, and it does indeed render fine, so I guess the rust implementation is functioning, just not enabled in stable.

... also, I see no evidence that it was ever enabled in the stable builds, even for the C++ version, so I'm guessing Zen just turned it on. Which... is fine, but maybe not very cautious.

by capitainenemo

1/21/2026 at 10:07:40 PM

zen browser is pretty much vibe coded

by awestroke

1/22/2026 at 12:02:54 PM

Do you have any proof/more about this? I've never heard this claim and I'd like to know more

by nar001

1/23/2026 at 3:24:49 PM

1. Zen Browser had remote debugging enabled by default and disabled the security prompt for it. Extreme incompetence or malice? https://github.com/zen-browser/desktop/pull/927

2. Social trackers are selectively allowed, unsigned extensions are enabled by default, and Enhanced Tracking Protection isn't fully implemented.

There's just a theme of incompetence, trying to cover it up and just in general being clueless about security.

by awestroke

1/22/2026 at 8:05:38 AM

good. image parsing has produced so many bad RCEs.

by bpbp-mango

1/22/2026 at 10:23:13 AM

Google Chrome is using a Rust implementation. The existence and sufficient maturity of it is the reason they were willing to merge support in the first place.

by rkangel

1/22/2026 at 8:57:20 PM

Hmmm, check the jxl-rs repository. I wouldn’t call it mature. Not to say it’s buggy, but most of its code is very fresh.

by illiac786

1/21/2026 at 10:27:14 PM

Flipping `image.jxl.enabled` made it work for me after refreshing the page. I'm using Librewolf 146.0.1-1, but I guess it works just fine in firefox 146

by dietr1ch

1/21/2026 at 6:15:41 PM

Works in ladybird as well.

by rhdunn

1/21/2026 at 9:00:32 PM

Support is not a boolean.

A proper test page should have HDR images, images testing if 10-bit gradients are posterised to 8-bit or displayed smoothly, etc...

iOS for example can show a JPEG XL image, but can't forward it in iMessage to someone else.

by jiggawatts

1/22/2026 at 9:26:20 AM

HDR support is an anti-feature. Nobody want a part of a website to suddenly be 10x as bright as pure white.

by mort96

1/21/2026 at 6:01:00 PM

JPEG XL is also good, but why not use AVIF? It's widely supported by browsers, and rivals JPEG XL in being the best lossy image format.

by uyzstvqs

1/21/2026 at 6:15:57 PM

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...

by judah

1/22/2026 at 1:25:12 AM

Strange, as Cloudinary's test had the opposite conclusion -- jpegxl was significantly faster to decode than avif. Did the decoders change rapidly in a year, or was it a switch to new ones (the rust reimplementation)?

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

If decode speed is an issue, it's notable that avif varied a lot depending on encode settings in their test:

> Interestingly, the decode speed of AVIF depends on how the image was encoded: it is faster when using the faster-but-slightly-worse multi-tile encoding, slower when using the default single-tile encoding.

by jomohke

1/22/2026 at 6:16:27 PM

>> 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.

This would be great.

by N19PEDL2

1/21/2026 at 8:05:46 PM

I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?

by quentindanjou

1/21/2026 at 9:18:21 PM

Taking advantage of hardware decoding is generally like pulling teeth.

For video you can't avoid it, as people expect several hours of laptop battery life while playing video. But for static images - I'd avoid the pain.

by michaelt

1/21/2026 at 6:19:18 PM

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.

by F3nd0

1/21/2026 at 6:16:56 PM

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

by Socket-232

1/21/2026 at 5:37:42 PM

Are there any up-to-date WebKit browsers for Android? The best I could find was Lightning, but it hasn't been updated in years.

Edit: I found A Lightning fork called Fulguris. It didn't work with the JPEG XL test image, but I really like the features and customizability. It's now my default browser on Android.

by dlcarrier

1/21/2026 at 6:10:05 PM

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).

by zamadatix

1/21/2026 at 6:01:45 PM

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

by TingPing

1/21/2026 at 8:10:12 PM

According to CanIUse, no browser implementation currently supports progressive decoding [1]. This is unfortunate, since progressive decoding theoretically is a major advantage of JPEG XL over AVIF, which doesn't allow it in principle, even though ordinary JPEG allows it. But apparently even a default (non-progressive) JPEG XL allows some limited form of progressive decoding [2]. It's unclear whether browsers support it though.

1: https://caniuse.com/jpegxl

2: https://youtube.com/watch?v=inQxEBn831w

by cubefox

1/21/2026 at 7:10:17 PM

A rare win for gnome web over firefox here

by samtheDamned

1/21/2026 at 5:08:33 PM

Alright, that image made be really miss Lenna as an example image.

by blell

1/21/2026 at 5:22:11 PM

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

by volemo

1/21/2026 at 5:06:57 PM

On Waterfox. Image displays fine.

by reef_sh

1/21/2026 at 7:07:42 PM

I enabled image.jxl.enabled in LibreWolf and works. It doesn't work in Firefox Beta, though?

by hotsalad

1/21/2026 at 7:38:26 PM

There's a jpeg xl viewer extension available for firefox.

by Frenchgeek

1/21/2026 at 5:14:47 PM

Epiphany (aka Gnome Web) on Linux shows this correctly, as expected for a Webkit-based browser.

by antonyh

1/21/2026 at 6:04:16 PM

If I download the image, Fedora KDE shows it properly in Dolphin and Gwenview.

by gary_0

1/21/2026 at 6:09:09 PM

> this means only Safari will display the image, as far as I know.

Works fine for me in Orion on both desktop and mobile ( https://orionbrowser.com ).

by ajdude

1/21/2026 at 6:19:22 PM

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

by seanclayton

1/21/2026 at 5:10:14 PM

Looks like the sort of person that would create a superior image file format.

by bigbuppo

1/23/2026 at 12:14:09 PM

Very good benchmark. Concise yet detailed. I like the selection of images. I wanted to see at least one actual camera photo however, for comparison.

by Incipient

1/21/2026 at 5:41:03 PM

I think JPEG XL's naming was unfortunate. People want to associate new image formats with leanness, lightness, efficiency.

by unglaublich

1/21/2026 at 6:43:56 PM

There was a constraint - since 2009, the Joint Photographic Experts Group had published JPEG XR, JPEG XT and JPEG XS, and they were probably reluctant to break that naming scheme.

They're running out of good options, but I hope they stick with it long enough to release "JPEG XP" :-)

by fleabitdev

1/21/2026 at 7:47:47 PM

JPEG XP would have been a nice name for a successor of JPEG 2000, I suppose :)

There's also a JPEG XE now (https://jpeg.org/jpegxe/index.html), by the way.

by jonsneyers

1/21/2026 at 7:44:04 PM

Incidentally, JPEG Vista would be thematically appropriate.

by spider-mario

1/22/2026 at 8:36:12 AM

They can tack on more letters, or increment the X, as required.

by extraduder_ire

1/21/2026 at 6:55:49 PM

Good one - made me and a coworker both LOL (in the literal sense) :D

by nocman

1/21/2026 at 8:42:01 PM

JPEG ME

by lencastre

1/21/2026 at 5:46:56 PM

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

by snowram

1/21/2026 at 5:47:34 PM

I feel like "jpeg" has generally become a shorthand for "low quality compressed digital picture"

by flexagoon

1/21/2026 at 8:38:47 PM

In the photography world it's shorthand for "photo unedited straight from the camera". Popular with Fujifilm cameras especially due to their 'film simulation' modes which apply basically a filter to the image.

by benbristow

1/21/2026 at 9:10:03 PM

Not really? Unedited would be some sort of raw. JPEG usually implies preprocessed by the camera

by doubletwoyou

1/21/2026 at 9:12:43 PM

I guess I meant unedited by the photographer manually (e.g. using Lightroom etc.)

Either that or a photo that has been edited from a RAW and is a final version to be posted online.

by benbristow

1/21/2026 at 7:28:58 PM

I feel like you need to find better places on the internet. It's no longer 1997 downloading from dial up.

by dylan604

1/21/2026 at 8:02:42 PM

What makes jpeg compression bad isn’t low bandwidth. It’s really good at compressing an image for that.

What makes jpeg bad is that the compression artifacts multiply when a jpeg gets screen captured and then re-encoded as a jpeg, or automatically resized and recompressed by a social media platform. And that definitely isn’t a problem that has gone away since dialup, people do that more than ever.

by notatoad

1/22/2026 at 7:01:00 PM

I'm not saying it's true, I obviously understand that not all jpegs are low quality and over compressed. That's just how the word is generally used by people, especially those outside of tech who aren't well versed in different image formats.

by flexagoon

1/21/2026 at 5:56:57 PM

"diJital PEGchure"

by dgan

1/21/2026 at 5:59:54 PM

Is it pronounced jay-peg or gee-peg?

by dlcarrier

1/21/2026 at 8:07:25 PM

Nah, that's WEBP, the most hated file format.

by bigbuppo

1/21/2026 at 5:58:21 PM

JPEG XS :D

by zamadatix

1/21/2026 at 6:18:16 PM

Excess?!? I certainly don't want any of that in my image encoding formats!

by recursive

1/21/2026 at 7:52:15 PM

Exactly. Image compression should excel at avoiding excess.

Though maybe some people think the JPEG committee is now creating spreadsheet formats...

by jonsneyers

1/21/2026 at 7:41:58 PM

It seems to me this point of discussion always tends to get way too much focus. Should it really raise concern?

Of all the people who interact with image formats in some way, how many do even know what an image format is? How many even notice they’ve got different names? How many even give them any consideration? And out of those, how many are immediately going to think JPEG XL must be big, heavy and inefficient? And out of those, how many are going to stop there without considering that maybe the new image format could actually be pretty good? Sure, there might be some, but I really don’t think it’s a fraction of a significant size.

Moreover, how many people in said fraction are going to remember the name (and thus perhaps the format) far more easily by remembering it’s got such a stupid name?

by F3nd0

1/21/2026 at 5:49:15 PM

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

by bobmcnamara

1/21/2026 at 5:55:14 PM

It has an operation mode where it can losslessly and reversibly compress a JPEG further, and "not a jpeg" wouldn't cover that.

by Dwedit

1/21/2026 at 8:09:47 PM

JPEG XL is the thing that makes your JPEG smaller?

by dragonwriter

1/21/2026 at 10:00:47 PM

JPEG XL is basically 4 codecs in one...

* A new lossy image Codec

* A lossless image codec (lossless modular mode)

* An alternative lossy image codec with different kinds of compression artifacts than those typically seen in JPEG (lossy modular mode)

* JPEG packer

Because it includes a JPEG packer, you can use it as such.

by Dwedit

1/21/2026 at 7:30:16 PM

Just call it JXL.

by edflsafoiewq

1/21/2026 at 7:37:10 PM

Pronounced jixel?

by ziml77

1/21/2026 at 7:50:07 PM

Pronounced like French « j’excelle » (I excel).

(Kidding.)

by spider-mario

1/21/2026 at 8:46:14 PM

Kidding? But I actually kinda like it!

by ziml77

1/21/2026 at 7:56:40 PM

Yes, and JAY EXCEL for the savages like me

by greenavocado

1/21/2026 at 6:44:12 PM

Nobody can keep you from forking the spec and calling yours JPEG SM.

by formerly_proven

1/21/2026 at 8:06:44 PM

Shouldn't that be JPEG℠ vs JPEG™?

by kps

1/21/2026 at 6:06:05 PM

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.

by OscarTheGrinch

1/21/2026 at 10:23:37 PM

I regularly work with images larger than 65,535px per side.

WEBP can only do 16,383px per side and the AVIF spec can technically do 65,535, but encoders tap out far before then. Even TIFF uses 32-bit file offsets so can't go above 4GB without custom extensions.

Guess which format, true to its name, happens to support 1,073,741,823px per side? :-)

by gcr

1/21/2026 at 7:08:11 PM

> Crappy as a .jpg, only bigger.

Honestly, that's exactly what it sounds like to me too. I know it's not, but it's still what it sounds like. And it's just way too many letters total. When we have "giff" and "ping" as one-syllable names, "jay-peg-ex-ell" is unfortunate.

Really should have been an entirely new name, rather than extending what is already an ugly acronym.

by crazygringo

1/21/2026 at 7:16:13 PM

I’ll never not say pee-en-gee. You’re right though.

by sillysaurusx

1/21/2026 at 7:43:05 PM

I always have called it PNG pee-en-ji, and JPEG XL for me has p much all the time been jay-x-el.

by NekkoDroid

1/22/2026 at 7:02:33 AM

It's JPEG Extra Lovely.

by bigbuppo

1/21/2026 at 5:54:13 PM

μJPEG

by catskull

1/21/2026 at 8:06:33 PM

And yet WEBP decided to associate itself with urine, which google then forced on everyone using their monopoly power.

by bigbuppo

1/21/2026 at 8:14:59 PM

JPEG 15 Pro Max

by DominoTree

1/21/2026 at 5:46:18 PM

Do you have anything to back this up?

by Almondsetat

1/21/2026 at 5:59:24 PM

Works on FireFox Focus on mobile, FWIW. (Latest iOS)

by sailfast

1/21/2026 at 6:28:34 PM

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

by cdmckay

1/21/2026 at 9:13:05 PM

Presumably the "January 2027" statement is a typo, ...or is that when it is slated to launch in safari?

by mattlondon

1/22/2026 at 9:42:09 AM

Safari started supporting it over two years ago.

by robertoandred

1/21/2026 at 9:16:21 PM

yeah, it's a typo :-)

by roywashere

1/21/2026 at 5:05:27 PM

Yep, doesnt work on firefox or chrome.

by PlatoIsADisease

1/21/2026 at 5:13:48 PM

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

by nticompass

1/21/2026 at 5:17:34 PM

Same for me, Zen 1.17.15b on Mac

by paularmstrong

1/21/2026 at 5:33:07 PM

Same I am using Zen 1.17.15b on Mac too and it works for me too

by Imustaskforhelp

1/21/2026 at 5:08:10 PM

Working fine on Firefox for me

Firefox version 146.0.1 on Windows 11

by _grilled_cheese

1/21/2026 at 5:14:13 PM

https://caniuse.com/jpegxl

I have the flag enabled but it's still broken in FF, needs to be a nightly build to work

by WithinReason

1/21/2026 at 5:20:48 PM

Same here, doesn't work, FF 148.0b5

by nor-and-or-not

1/21/2026 at 6:09:46 PM

Cannot see it with lockdown mode iOS

by jbverschoor

1/21/2026 at 5:30:46 PM

On zen. It works.

by Imustaskforhelp

1/21/2026 at 6:54:43 PM

I can see the image just fine on Thorium!

by Redster

1/22/2026 at 12:53:32 PM

> more or less means only Safari will display the image

Who is going to take the bait, and say that Safari isn't like IE?

by jiehong

1/21/2026 at 5:20:55 PM

Looks like it works in Brave

by oldcoot

1/21/2026 at 5:25:21 PM

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

by mdasen

1/22/2026 at 12:59:00 AM

Doesn't work in Brave. (Using v1.86.139)

by theandrewbailey

1/21/2026 at 5:37:12 PM

Doesn't work for me on Brave on Android

by iberator

1/21/2026 at 6:04:52 PM

Works in Waterfox (6.6.8)

by jordemort

1/22/2026 at 11:23:54 AM

Unrelated but I read "it did not saw" and immediately thought, this person is Dutch. Then I saw the .nl domain. Not sure if this double-conjugation mistake is common in other ESL speakers but I hear it a lot living in the Netherlands.

by billynomates

1/22/2026 at 12:04:58 PM

Is the selectable text a safari thing or a JPEG XL thing?

by thatgerhard

1/22/2026 at 12:13:53 PM

"Live Text" is a iOS/macOS feature. Works in Safari, camera, photos.app, etc…

by Alcor

1/21/2026 at 5:59:24 PM

Honestly I was hoping for a page showing off more of jpeg xl features rather than just a single image

by adzm

1/21/2026 at 7:26:46 PM

You probably want the JPEG XL Info[1] site then. A nice site outlining what JPEG XL actually is.

[1] https://jpegxl.info/

by wmwragg

1/21/2026 at 7:49:09 PM

While I get why, it bugs me that they have comparison images between jxl and other formats, yet it doesn't actually use jxl, as evidenced by all images displaying correctly on my chrome browser.

by amarant

1/22/2026 at 1:46:58 AM

This is standard practice. They need to use current lossless formats to display examples to people who don't have the format yet. They are still showing accurate examples of compression artifacts. I'm not sure what else you'd expect them to do.

by jomohke

1/22/2026 at 9:45:31 AM

can you please:

* add an correct HTML image alt information

* compress your HTML and CSS with brotli (or gzip)

thanks!

by gforce_de

1/22/2026 at 2:49:46 PM

[dead]

by russiancupid

1/21/2026 at 6:06:34 PM

Works with Waterfox on macOS but curiously not Firefox. I wonder if their search deal with Google included keeping the image.jxl.enabled setting off.

by davidhyde

1/21/2026 at 6:14:13 PM

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.)

by F3nd0

1/21/2026 at 6:07:57 PM

Works on Zen as well.

by quaintdev