Been reading about JPEG XL - Chrome just started supporting it in February
Safari has supported it longer - Firefox looking to support in the future…
Seems to be a really good format and better compression….
Anyone making the switch?
Why or Why not?
1 Like
@dan Something for Squash?
Yes 
would be very nice for squash….
From Chat GPT:
This is where things get beautifully nerdy.
Short answer: JPEG XL can be one master file that serves both photography and web — but in practice you often generate different encodes from that master.
Let’s untangle that.
JPEG XL was designed as a universal format. Not “a web format” and not “a pro photography format.” Just… an image container that scales from tiny thumbnails to 100-megapixel HDR art prints without changing formats.
That’s unusual.
Older world:
- RAW → edit → export JPEG (print)
- Resize → export separate JPEG/WebP (web)
Different files. Different compromises.
JPEG XL was built to collapse that split.
Here’s how.
It supports:
• High bit depth (10–16 bits per channel)
• Wide color gamuts (Display P3, Rec.2020)
• HDR
• Lossless compression
• Progressive decoding (web-friendly loading)
• Embedded previews and multiple resolutions
• Lossless recompression of old JPEGs
So yes — technically, you could keep one high-quality JPEG XL master that:
- Preserves full dynamic range for archival or print
- Still loads progressively and efficiently in a browser
It’s like having a studio master tape that can also stream efficiently.
But reality enters the room.
A 16-bit HDR master file might be:
- Larger than necessary for a blog post
- Overkill for most 8-bit SDR displays
- Potentially unsupported on parts of the web stack
So in practice, photographers often:
- Keep a high-quality or lossless JPEG XL master.
- Export a slightly lower-bitrate JPEG XL for web delivery.
(Or WebP/AVIF fallback depending on browser support.)
Same format. Different compression settings.
Think of it like exporting different MP3 bitrates from the same WAV file. Same source, different delivery targets.
Now here’s the elegant twist.
JPEG XL supports something called progressive decoding with quality layers. That means the image can load blurry and sharpen progressively — but it’s still the same file. No separate “thumbnail version” needed.
Even wilder: it can losslessly convert an existing JPEG into JPEG XL and back again without generational loss. That’s extremely unusual in compression formats. It was designed as a true evolutionary bridge.
So the conceptual model:
Old mindset:
Format determines purpose.
JPEG XL mindset:
Compression settings determine purpose.
Same container. Different intent.
The only real limitation right now isn’t technical — it’s ecosystem support. If every browser fully supported JPEG XL tomorrow, many workflows would simplify dramatically.
Here’s the clean takeaway:
• You can use one JPEG XL master for both photography and web.
• You’ll often still export different encodes for performance reasons.
• The format itself doesn’t force the split — workflow does.
Formats are like musical instruments. JPEG was a piano. WebP was a synthesizer. JPEG XL is trying to be a modular studio — capable of orchestral nuance and streaming efficiency in the same box.
The question isn’t “one version or two?”
It’s “how much fidelity does this moment require?”
And that’s a philosophical compression problem as much as a technical one.
My personal thoughts are that it’s too early to be using JPEG XL. If you do start using it you’d need to provide fallback images for the browser that don’t support…
What were you hoping to gain by using it?
Better quality images, better compression - sounds like the future….
But yes - your right… fall back images would stink…
I am also looking to the future of my image storing and archiving…
Coming from an audio perspective- I hate mp3
I would much rather have 24bit 48k recordings - more resolution- better listening experience….
Kind of the same with images - prefer higher quality- less compression and artifacts…
Found out another use of JPEG xl
Transparent images for dark mode!
Didn’t know about this…
From Gemini:
Yes, .jxl (JPEG XL) supports transparency.
It actually handles it significantly better than the old JPEG format (which has zero transparency support) and even outperforms PNG and WebP in several technical ways.
Here is why .jxl is a powerhouse for those transparent images that are currently causing you headaches:
- The “Alpha Channel” Support
In technical terms, JPEG XL supports an Alpha Channel. This is the extra layer of data that tells the browser which parts of the image should be see-through.
- Unlike PNG, which can get very “heavy” when you have complex transparency, .jxl uses a more modern compression method that keeps the file size tiny while maintaining perfectly crisp edges.
- It supports both lossy (smaller files, slight quality loss) and lossless (perfect quality, larger files) transparency.
- Why it helps with your “Dark Mode” issue
If you are struggling with images that have white backgrounds, converting them to .jxl (with the background removed) is a great 2026 solution:
- Smaller Footprint: A transparent .jxl is often 50-70% smaller than a transparent .png. This means your 90-page site will stay lightning-fast even if you replace all those “white background” JPEGs with transparent versions.
- Higher Fidelity: It supports a higher “bit depth,” meaning if your images have soft shadows or glows (which often look “crunchy” or pixelated in WebP), .jxl will render them smoothly.
- Browser Support (The 2026 Update)
This is the most important part for your workflow. For a few years, Google Chrome had disabled .jxl support, which made it risky to use. However:
- As of early 2026, Chrome has officially brought back JPEG XL support (starting with version 145).
- Safari and Firefox have supported it for a while now.
- The Result: It is now safe to use .jxl as a primary format for your RapidWeaver Elements sites without worrying about half your visitors seeing a broken image icon.
Pro Tip for Elements Users
If you want to fix those 90 pages of white-background images: - Open the original image in an editor (like Pixelmator Pro or Affinity Photo).
- Use the “Remove Background” tool.
- Export as JPEG XL (.jxl).
- Drop it into Elements.
Because the background is now truly transparent, it will automatically adopt whatever color you set in Theme Studio (Light or Dark), and you’ll never have that “flashlight” effect again.
Would you like me to find a tool or a Mac shortcut that can batch-convert your existing white-background JPEGs into transparent .jxl files?
Standard formats are something I watch carefully, particularly when it comes to images, as all my sites deal with images and photography.
In terms of the Web, lowest common denominator generally has to be adopted. Everything supports JPEG, so that’s “safe.” Everything now seems to support PNG, so that, too, is now considered “safe.” WEBP is next in that progression.
JPEG XL has been around for a very, very long time. The fact that it’s not standard in Web rendering should tell you something. It’s not solving the right problem.
What you really need to watch is what is happening with HDR, because that will be the next necessary standard that all the browsers need support. This is being driven by both the input/processing devices (cameras, image processing software) as well as the output capability (displays). This standard is coming sidewise via video, where their HDR standards are already defined and fully in play.
If you want to see what’s happening, go to Greg Benz’s page on it: Create and edit true HDR (High Dynamic Range) images - Greg Benz Photography. All the pressure at Apple/Google/Samsung is around moving from SDR to HDR. Thus, I expect the next Web “standard” for rendering is likely going to have to develop around HDR. And in particular, what Greg describes as HDR with an SDR gain map. This addresses the lowest common denominator problem, as if your display can’t handle HDR, you get an SDR simulation.