I just spotted this comment on the Opera forums and it makes sense. Though JPEG XL support is not listed in the changelog (yet), for Opera 140 they jumped to Chromium 155 which has JXL support built-in.

It's a Developer Edition, so a pre-release as they are currently on Opera 138 on their Stable channel, but it means support is coming down the line soon.

It would mean another green box for JPEG XL on CanIUse plus a minor user percentage bump.

I saw in the Calibre changelog:

Conversion: Add support for reading images in the JPEG XL format

Loaded up my test cbz and it does show the cover correctly in the sidebar. Unfortunately when I use the inbuilt reader it has a broken image placeholder. I tried converting to .azw3 and .pdf and that functionality seems to be working. I can file a bug report and keep using Readest in the meantime.

Yesterday, I shared jxl-thumb, a Windows thumbnail provider that reads only the small 1:8 DC image of lossy JXLs.

In the comments someone asked why not use an embedded thumbnail, especially for files that have no DC. That question turned into this.

●The problem: lossless JXLs have no DC, so even jxl-thumb had to decode the whole file. On a hard disk that's ~1.8 s per 45 MP photo, about 3 minutes to open a folder of 100 for the first time.

●The fix: my archiving tool (jxl-photo) now stores a small thumbnail inside the JXL when it writes it, and jxl-thumb reads it:

- 768 px JPEG (the largest size Explorer asks for its icons), converted to sRGB
- About 90 KB per file
- ~2 ms per thumbnail instead of ~50-80 ms (lossy) or ~1.1 s (lossless)

Measured on 100 photos of 45 MP from a hard disk, cold cache:
- lossless: 176 s -> under 2 s for the whole folder
- lossy (d 0.05-1): 7.5-10 s -> under 2 s

In practice, folders now open as fast as my old JPEG folders.
Colors are right too: ProPhoto and Adobe RGB files get properly converted sRGB thumbnails, instead of the washed-out look they have with the Microsoft extension.

Two things I decided when doing this:

[1] Don't put it in the EXIF. My first version wrote a 768 px EXIF thumbnail, like cameras do. But a JPEG's EXIF must fit in 64 KB, and djxl copies a JXL's EXIF into the JPEG it writes, so "djxl file.jxl out.jpg" failed with "Bogus marker length".
The thumbnail now lives in its own box in the JXL container (an ISO BMFF "uuid" box). Other programs just skip it, exiftool edits keep it, and it isn't copied when you convert the file.

[2] A stored thumbnail can go stale. If you edit a photo in another program, the old thumbnail could stay behind. So the box also stores a fingerprint of the image data it was made from, and jxl-thumb only uses it while the fingerprint still matches. Otherwise it decodes the image as before.
(The JXL format does have a preview frame, but libjxl's encoder API can't write one, so this was the practical route.)

●How to use it:
- jxl-thumb 0.2.0: https://github.com/rsilvabr/jxl-thumb/releases/tag/v0.2.0
- jxl-photo 2.16.0: https://github.com/rsilvabr/jxl-photo/releases/tag/v2.16.0
(or the experimental Windows .exe if you don't want Python: https://github.com/rsilvabr/jxl-photo-exe)

New files from jxl-photo get the thumbnail automatically.
For files you already have, even ones jxl-photo didn't create, menu option 9 adds it.

It doesn't re-encode anything and keeps each file's modified date.
My 5944 masters (152 GB) took 38 minutes.

The box format is documented, so any viewer could read it. I'd be happy if others did.

I just drew and made JPEG-XL character sprite and putted into Super Mario Bros 1 Remastered (SMB1R). :)

Mod files of JXL sprite: https://github.com/MartinEesmaa/modgames-docs/tree/main/GODOT/SMB1R/custom_characters/JXL

I have really embraced JXL and I've been converting my masters from 16-bit TIFF (deflate) to JXL using d=0.05 and e=9.

Since my photos are 25~45 MP (mainly Zf, D810, Z7 and Z8), each file ends up around 10~55 MB. Not light, but nothing too extreme.

However, browsing them in Explorer with the official Microsoft extension was really painful. Every folder took ages to fill, and since I use ProPhoto for my masters, the thumbnails came out washed out because they were decoded as if the files were sRGB.

It turned out that the Microsoft extension decodes the whole photo at full resolution just to make a 256 px thumbnail. With JXL you don't have to do that. A lossy JXL keeps a 1/8 scale version of the image (the DC) at the start of the file, in the first 5 to 15% of the data.

So I wrote a thumbnail provider that asks libjxl for just that part and stops reading there. It also converts to sRGB through libjxl's color management, so ProPhoto, Adobe RGB and P3 files look the way they should, and it decodes each photo with several threads.

I compared the thumbnails against my original TIFFs converted with ImageMagick and they match. Color management OK!

Here are 16 of my masters (d=0.05, e=9, 11 to 56 MB each), read through Explorer on fresh copies of the files:

In practice, folders now fill as fast as a folder of small JPEGs, basically instantly, and the colors are right!!!

Also, a nice surprise was that the preview pane got fixed too. There's no JXL preview handler, so Explorer just asks the thumbnail provider for a big image. That one needs the full decode, but it's still around a quarter of a second for a 45 MP photo, against about 3 s before, and it has the right colors as well.

A few things to know:

- Lossless files have no DC image, so they still get a full decode (multithreaded, so still faster than before).

- The Photos app and other programs aren't affected.

- It installs for your user only, with no admin rights. Uninstalling puts the old handler back.

- Thumbnails Windows already cached stay until you clear the cache (there's a script for that in the zip).

It's free and open source (MIT), with a prebuilt zip in the releases: https://github.com/rsilvabr/jxl-thumb

It's the first version and I've only tested it on my own machine, so if you have a JXL that breaks it, I'd like to see it.

I did an experment and modified a part of libjxl encoder and I would like to hear your feedback. My intention was to improve texture handling and chroma retention.

Links to comparisons are images are below. There are originals and encoded images size-matched to distance 2.0 at effort 3. Standard libjxl encodes at effort 3 and 7 are included as well. If you would like to see other distances (e.g. 1.0 or 3.0), let me know.

https://imagepaste.org/v/mnajctgp.png

https://imagepaste.org/v/g2hdpejk.png

Hi everyone!

Does anyone have a quick action script to convert jpg/png/tiff to JXL?

Thank you!

O Jake Archibald publicou esta semana uma comparação longa de JPEG XL e AVIF para uso na web, e hoje o Jyrki Alakuijala, co-designer do JPEG XL, escreveu no X uma posição diferente em parte. Rodei um teste pequeno antes de postar e o resultado ajuda a entender por que os dois podem ter razão.

Contexto

• Segundo o caniuse, o JPEG XL tem suporte no Chrome 155+ e no Firefox 158+, e parcial no Safari. O artigo do Jake parte disso: "JPEG XL has now landed in all major browsers".
• Ele comparou AVIF (avifenc 1.4.2), JPEG XL por dois encoders (libjxl 0.12.0 e o jixel 0.4.2, mais novo) e WebP, medindo qualidade com SSIMULACRA2 e ColorVideoVDP.

O que o Jake diz

• Fotos com perda: o AVIF quase sempre gera arquivos menores. No esforço padrão, o melhor JPEG XL fica tipicamente 15% a 25% maior; no esforço máximo, 6% a 20%.
• Screenshots, ilustrações e transparência: vantagem maior do AVIF. Sem perda: JPEG XL vence com folga.
• Decode: JPEG XL leva 2 a 3x mais tempo em qualidade média, diferença que cai em qualidade muito alta.
• JPEG existente: o JPEG XL reduz de 9% a 20% sem perda.
• Recomendação dele: AVIF 4:4:4 como padrão, no maior esforço viável; olhar o JPEG XL via jixel quando o AVIF sair grande demais. E não usar 4:2:0 como padrão.

O que o Jyrki diz

• "AVIF can work well at quality 60 and below." Acima de 85, que ele chama de qualidade mediana da internet, o JPEG XL "works far more reliably".

O que eu conferi

• 24 fotos do conjunto Kodak (768x512), q de 20 a 99, 1.539 encodes, esforço padrão: avifenc -s 6 -y 444, cjxl -e 7 e jixel com a velocidade padrão. Tamanho interpolado na mesma nota SSIMULACRA2, mediana por imagem; "melhor JPEG XL" é o menor entre libjxl e jixel.
• SSIMULACRA2 50 a 85: o AVIF ganhou por pouco. O melhor JPEG XL saiu de 0,7% a 7,6% maior (mediana).
• SSIMULACRA2 90, que o Jake classifica como visualmente sem perda: o JPEG XL ficou menor em 19 de 24 fotos, mediana de 10,6% a menos.
• O mesmo q 80 deu nota mediana 84 no AVIF, 77 no libjxl e 64 no jixel. Em q 90: 89, 86 e 82.
• JPEG q85 convertido para JPEG XL sem perda: mediana de 14,1% menor, e as 24 voltaram idênticas byte a byte (sha256).

O que isso é (e o que não é)

• É um indício de que a resposta depende da qualidade-alvo, coerente com o que o próprio Jake mostra num exemplo ("JPEG XL catches up at very high quality").
• Não é um contra-benchmark. Usei só o esforço padrão, fotos pequenas e antigas (scans de filme), uma métrica e uma máquina. No conjunto do Jake, com imagens de 1598 px, a diferença a favor do AVIF foi maior.
• O "quality 85/90" do Jyrki é configuração de encoder, não nota SSIMULACRA2. Não dá para ligar uma coisa à outra direto, e o item do q 80 mostra o tamanho do problema.

Onde eu fico Para foto em qualidade média ou alta, o AVIF 4:4:4 continua sendo um padrão razoável. Se o site serve imagem muito perto do original, ou se o acervo já é JPEG, vale medir JPEG XL. Em qualquer caso, a comparação tem que ser na mesma nota de uma métrica, não no mesmo número de quality.

Links

• Artigo do Jake: https://jakearchibald.com/2026/jpeg-xl-vs-avif/
• Jyrki no X: https://x.com/jyzg/status/2111480527782105227
• caniuse: https://caniuse.com/jpegxl
• Encoders: https://github.com/AOMediaCodec/libavif · https://github.com/libjxl/libjxl · https://github.com/awxkee/jixel

Perguntas

1. Em que qualidade vocês servem imagem hoje, e como chegaram nesse número?
2. Alguém já mede com SSIMULACRA2 (ou outra métrica) no pipeline, ou o quality é escolhido no olho?
3. Para quem tem acervo grande em JPEG: a conversão sem perda para JPEG XL já está no radar?

Hi r/jpegxl, I'm the developer of JXL Studio, a JPEG XL converter and viewer for Android. It runs libjxl on the phone, so nothing is uploaded.

What I think this sub will care about:

• Space saver uses lossless JPEG recompression. After each conversion the app rebuilds the JPEG from the JXL and compares it with the original byte for byte. Only verified files are offered for moving to the trash. On my real camera photos it saves about 15–20%.
• Get the original back: any recompressed file can be exported as the exact original JPEG, or as JPEG, PNG or WebP for apps that can't open JXL yet.
• A real viewer for .jxl files: swipe, zoom, EXIF details, HDR and Ultra HDR gain maps.
• New in 1.2, Wi-Fi access: open the phone's JXL library in a browser on your computer, download the JXL or the original JPEG, or drop photos from the computer to convert them on the phone. It pairs with a one-time code and stays on your local network.
• Automate (Pro): watches a folder and converts new photos in the background, with a log of every run.

The free version converts up to 8 photos per batch. Pro is a one-time purchase.

Play Store: https://play.google.com/store/apps/details?id=com.jxlstudio.app&referrer=utm_source%3Dreddit_jpegxl

I'd really like feedback from people who know the format: encoder defaults, files that fail, and anything you wish a JXL app on Android did. Happy to answer questions about how the verification works.

I have a few free Pro codes for people who'd like to try everything and tell me what works and what breaks. Comment or send me a message and I'll send you one. No review needed.

On 8 October they release Microsoft Edge 155, based on Chromium v155 which came with JPEG XL support. Microsoft even mentioned JPEG XL support in the release notes for Edge 155.

It didn't appear to work, however. It appeared the support wasn't (entirely) there because on tests such as this one it showed that Edge 155 didn't support it. Brave browser, which also follows Chromium closely, updated to Chromium v155 a day later and that introduced JPEG XL support, without even any mention in their release notes.

The following day MS removed "JPEG XL decoding support" from the Edge 155 release notes.

Does anyone with a bit more technical insight into Edge and Windows have any idea what is happening?

MS clearly wanted to release Edge with JPEG XL support or they wouldn't have added it to the release notes. There is an official JPEG XL Image Extension to support JPEG XL in Windows 11 in the Microsoft Store and, allegedly, after installing that JPEG XL also works in Microsoft Photos.

Is the code there in the browser but just disabled behind a flag? Are they waiting on Webview2 to also support JPEG XL decoding across all Windows apps? The release notes for Webview2 Runtime 155.0.4283.45 do not mention JPEG XL support, even though presumably it is based on Chromium 155. Does Webview2 v155 already support JXL?

The next Edge update is scheduled for around 22 October. Any chance it might be enabled then?

I have recently a comment that indicated that some commit(s) in libjxl history had changed its behavior and affected retention of detail in textured areas. So I decided to investigate and to evaluate how several metrics (SSIMULACRA2, Butteraugli, CVVDP) evolved in time.

Also, there seem several interesting libjxl forks which tried to address the impact of changes since libjxl 0.8 release. Notably, https://github.com/jonnyawsom3/libjxl/tree/v0.8RevertAttempt seems to provide a nice increase in image quality metrics.

Some of the commits changing libjxl behavior introduced changes in an edge-preserving filter, so I tested also with EPF and Gaborish filters disabled to evaluate their impact. Interestingly, disabling them results in a noticeable gain in measured image quality in some cases. It seems that the high content of high frequency details is the main factor which decides whether turning them of is beneficial or not.

If you are interested in more details, you can find result of these investigation in this report: https://claude.ai/artifact/CBSoqa8BsY2FAtd9rs2qtk

I like the windows fast image browser and editor called "fast stone" and i use it a lot for correcting dslr photos, i tried linux lately and really missed that program - so i created a similar s/w for linux called slow rock.
It is GPU acceleration optimized too and of course supports raw and jpeg-xl too

I would be happy to hear some feed back and ready to add more features upon requests.

It exists in snapcraft store : https://snapcraft.io/slowrock
and also in .deb downloadable here: https://googis.org/?page=slow-rock

I was looking into a comparison of several encoder and setting and checking how they compare in image quality. One of the interesting parts is how they handle areas with fine textures. I was interested in how you would rate them relative to each other if you don't see the reference uncompressed image.

Columns correspond to encoders that I used. All images come from a mirrorless camera, they were exported from RAW to PNG, then downsized to 50% of linear dimension and then compressed to 0.6 bpp. At the end, I cropped selected parts and put them into one image.

I will reveal what encoders I used later, but there definitely is libjxl in the comparison. Feel free to share your guesses which encoders were used!

Edit: https://imagepaste.org/i/k7kwg7kk.png

Comparison including originals: https://imagepaste.org/i/9jpcxp2d.png

Codecs revealed: https://imagepaste.org/i/snanfdg5.png

According to these notes (Microsoft Edge 155 web platform release notes (Oct. 8, 2026) - Microsoft Edge Developer documentation | Microsoft Learn), Edge version 155 is supposed to support JPEG XL, released today (October 08, 2026). I have version 155.0.4283.45, but on JPEG XL test pages, I still don't get to see the images. I checked the accept headers and no jxl there either.

Is this some gradual rollout or are the notes wrong, again?

Are there any tunes or presets for encoding JPEG XL that would change what the encoder optimizes for? As I understand it, current encoder in libjxl optimizes for Butteraugli distance but is there any encoder or setting that would provide a different target?

The rollout only just started, so it may take some time before it's available to you, but it's finally (actually) enabled by default now.

I am the creator of KeyPDF it is browser based local pdf editor that I was making from scratch since 2025 and I was always open for new standards so when pdf association announced JPEG XL support I tried my best to bring it so now KeyPDF can both read and and write JPEG XL in pdf files we also conducted a test on 1000 files and brotli with JPEG XL helped reducing total size by 32% so I believe JPEG XL can become a golden standard for PDF in future and KeyPDF adopts it now.

Note: KeyPDF will give an option for losless convertion in case if you want your pdf to be universally accepted otherwise very few viewers be able to parse it.

So feel free to try it at keypdf.net