The Format That Should Not Still Exist
JPEG turned 30 in 2022. It was designed in an era when a 28.8k modem was considered fast, hard drives were measured in megabytes, and the web did not yet exist in any recognisable form. The engineers who built it were solving a specific problem: how do you compress a photograph well enough to fit on a floppy disk without making it look like a watercolour painting?
They solved it brilliantly. JPEG's discrete cosine transform is an elegant piece of applied mathematics, it breaks an image into 8×8 pixel blocks, converts each block into frequency components, and discards the high-frequency detail your eye is least likely to notice. In 1992, this was revolutionary. In 2026, it is a 34-year-old compression algorithm running on hardware its creators could not have imagined, serving a web that processes more images in a day than they would have seen in their entire careers.
JPEG persists not because it is good. It persists because it is everywhere. Every camera, every browser, every operating system, every image viewer on the planet speaks JPEG fluently. That ubiquity is both its greatest strength and the thing making it extraordinarily difficult to kill.
But something is trying. And it is remarkably well-armed.
What JPEG XL Actually Is
JPEG XL the XL stands for "Extra Large," a nod to its support for high-resolution, high-depth images was finalised as ISO/IEC 18181 in 2022. It emerged from a competition run by the JPEG standards committee, where two proposals were submitted: Google's PIK codec and Cloudinary's FUIF (Free Universal Image Format). Rather than picking a winner, the committee merged them into something better than either, a decision that turned out to be prescient, because the resulting format combines PIK's compression efficiency with FUIF's flexibility.
The lead architects were Jon Sneyers from Cloudinary and Pieter Wuille, the latter being one of the Bitcoin Core developers, which tells you something about the calibre of people who found this problem interesting enough to dedicate years of their life to it.
The result is a format with a specification that reads like a wish list someone wrote after being personally frustrated by every image format that came before it.
The Numbers: How Much Better Is It, Really?
Benchmarks in the image compression world are notoriously slippery, results vary by image content, quality settings, and which metric you use to measure visual fidelity. But the honest numbers, averaged across large, diverse image corpora, are hard to ignore.
| Format | vs. JPEG (same quality) | Lossless | HDR | Transparency | Animation |
|---|---|---|---|---|---|
| JPEG | Baseline | ❌ | ❌ | ❌ | ❌ |
| WebP | ~25–34% smaller | ✅ | ❌ | ✅ | ✅ |
| AVIF | ~40–50% smaller | ✅ | ✅ | ✅ | ✅ |
| JPEG XL | ~50–60% smaller | ✅ (better than PNG) | ✅ | ✅ | ✅ |
At matched visual quality, measured using the Butteraugli perceptual metric that JXL's quality system is built around, JPEG XL consistently produces files 50 to 60 percent smaller than an equivalent JPEG. That is not a marginal improvement. At scale, that is the difference between a website that costs $3,000 a month in CDN bandwidth and one that costs $1,200.
But the raw compression numbers are not even the most interesting part of the story.
The Feature Nobody Talks About: Lossless JPEG Recompression
Every other next-generation format requires you to decode an existing JPEG into raw pixels and re-encode it. In doing so, you lose information. The original JPEG was already a compressed approximation of reality; re-encoding it compounds the approximation. You end up with a smaller file and a slightly worse image than what you started with.
JPEG XL can do something no other format can: losslessly transcode an existing JPEG into JXL format. The resulting .jxl file is bit-for-bit identical to the original JPEG when decoded. You can also recover the original JPEG perfectly from the .jxl file, not an approximation, the actual bytes.
And the compressed JXL is roughly 22% smaller than the original JPEG it was created from, while containing all of its information.
Think about what this means for the web. There are hundreds of billions of JPEG images stored on servers, CDNs, and object storage around the world. Migrating them to any other format means re-encoding - quality loss, tooling overhead, validation work. Migrating them to JXL means running a lossless transcoder and ending up with a 22% smaller file you can still decode back to the original JPEG whenever you want. The migration path is reversible.
This one feature, if browser support existed, would be sufficient to justify migrating the entire web's image archive to JPEG XL. No other format offers this. Not WebP. Not AVIF. Not anything.
Everything Else It Does Better
Beyond compression ratios, JPEG XL was designed to eliminate the specific frustrations of every format that came before it:
- Bit depth: JPEG is limited to 8 bits per channel. JXL supports 1 to 32 bits per channel, covering everything from binary images to HDR photo archives and scientific imaging.
- Resolution limits: JPEG has a 65,535 × 65,535 pixel limit. JXL supports images up to one million by one million pixels, relevant for satellite imagery, medical scans, and gigapixel photography.
- Colour gamut: JPEG was designed for sRGB. JXL natively supports wide-gamut colour spaces including Display P3 and Rec. 2020, matching modern phone displays and professional monitors.
- Progressive decoding: JXL's progressive mode is genuinely useful, the image renders at lower quality first and sharpens as more data loads, making pages feel faster even before the image is fully decoded.
- Parallel processing: The format was designed from the ground up for modern multi-core CPUs. Encoding and decoding can be fully parallelised across cores in a way JPEG, a fundamentally sequential format - cannot.
- Error resilience: JXL is substantially more robust to file corruption than JPEG, where a single bit flip in the wrong place can make an entire image undecodable.
- Royalty-free: No patent licensing, no royalty fees, no legal uncertainty. This matters more than most people realise, it is why WebP won over JPEG 2000, and why AVIF is preferred over HEIF.
On paper, JPEG XL is not just the best image format available. It is the best image format that has ever existed. It is better than JPEG at lossy compression. Better than PNG at lossless compression. Better than WebP at almost everything. Competitive with or better than AVIF across most real-world image types.
So why is it not everywhere?
The Browser Support Disaster
In May 2021, Chrome 91 added JPEG XL behind a feature flag: --enable-features=JXL. Developers could experiment. Interest was significant. The image community was optimistic.
In February 2023, Chrome 110 removed the flag entirely. JPEG XL support was gone from the world's most popular browser, with no announced timeline for restoration.
Google's stated reason was, essentially, that ecosystem adoption was not sufficient to justify the maintenance burden. The decision was met with immediate and sustained backlash. The Chromium bug tracker issue requesting JXL support accumulated over 1,000 stars, an unusually high number for a browser feature request, indicating significant developer frustration. Contributors pointed out the circular logic: ecosystem adoption cannot grow if the dominant browser does not support the format.
The unspoken context is that Google has significant investments in competing formats. They created WebP. They are a primary contributor to AVIF through the Alliance for Open Media. JPEG XL's superior compression in some categories is, from a certain angle, inconvenient for those investments.
This is not a conspiracy. It is a rational corporate decision. But it is worth naming clearly when trying to understand why the technically superior format is not winning.
The current browser support table looks like this:
| Browser | JXL Support | Notes |
|---|---|---|
| Safari 17+ | ✅ Native | Full support since September 2023 |
| Firefox | ⚠️ Flag only | media.jxl.enabled in about:config |
| Chrome | ❌ Not supported | Removed in Chrome 110 (Feb 2023) |
| Edge | ❌ Not supported | Chromium-based, follows Chrome |
| Opera | ❌ Not supported | Chromium-based, follows Chrome |
That Safari column is more significant than it looks. Safari is the default browser on every iPhone and iPad. Apple's mobile market share means that a meaningful percentage of web traffic comes from browsers that can natively render JXL. It is not universal support, but it is not nothing either.
The Format War Nobody Asked For
JPEG XL does not exist in isolation. It arrived into a market already fragmented by competing next-generation formats, each backed by enormous organisations with reasons to prefer their own candidate.
WebP - Google's 2010 format, spent years in browser support purgatory before finally achieving universal support around 2021. It delivers respectable compression improvements over JPEG and is now safe to use everywhere. But it was designed in 2010, and compression research has advanced considerably since then.
AVIF - based on the AV1 video codec developed by the Alliance for Open Media (Google, Apple, Microsoft, Mozilla, Netflix, Amazon, and others), is the format most likely to challenge JPEG XL for next-generation supremacy. It achieves excellent compression, especially at low quality settings, and has rapidly gained browser support. Its weakness is encoding speed: AVIF encoding is significantly slower than JXL encoding, which matters when converting large image libraries.
HEIC/HEIF - Apple's default camera format since iPhone 11, uses HEVC (H.265) compression and is excellent for photographs. But it carries patent licensing uncertainty that has kept it out of open-source browsers and made web adoption essentially impossible outside the Apple ecosystem.
Of these, JPEG XL has the best compression, the fastest encoding, and the most features. It also has the worst browser support. This is the central paradox of the format's existence.
Why JPEG XL Will Eventually Win
The argument for JXL's eventual dominance comes down to a few structural advantages that do not disappear with time.
Apple is committed. Safari's support for JXL is not accidental. Apple has historically been the company that drives adoption of image formats that align with their interests, they forced the web onto WebP by refusing to support it until 2020, making every developer maintain both formats. Their full JXL implementation in Safari 17 signals a strategic commitment, not an experiment. As Apple Silicon continues to spread across MacBooks and iOS devices, the percentage of web traffic from JXL-capable browsers grows with it.
The JPEG recompression argument is economically compelling. When a major CDN runs the numbers on serving 22% smaller files with zero quality loss across their entire JPEG cache, the financial case becomes obvious. Cloudinary, whose team co-created JXL already supports the format. As other CDNs and image processing services add JXL support, the infrastructure is being quietly built out regardless of what Chrome does.
Firefox could flip the switch any day. Mozilla has implemented JXL. The flag is there. The code is there. The decision to enable it by default is a product decision, not an engineering one. Given Mozilla's history of championing open standards over corporate interests, and given that Apple enabling JXL removes the "no ecosystem" argument, Firefox enabling JXL by default is more a matter of when than if.
Chrome's position is reversible. The Chromium team removed JXL because ecosystem adoption was insufficient. Ecosystem adoption is increasing. Safari's support changes the calculus. If Firefox enables JXL, the two non-Chrome browsers will both support it, which substantially weakens Chrome's "insufficient demand" argument. The decision could be reversed in a single browser release cycle.
The technical case only gets stronger. AVIF's main advantage over JXL is current browser support, not technical merit. As hardware acceleration for JXL decoding is added to more chipsets and as the reference implementation continues to improve encoding speed, the technical gap widens in JXL's favour.
Why It Has Not Won Yet: An Honest Assessment
Being right is not sufficient. Being technically superior is not sufficient. Formats live and die by adoption, and adoption is driven by compatibility.
Today, if you serve a JXL image to a Chrome user, which represents roughly 65% of global browser share, they see nothing. Or they see a broken image icon. Either way, the experience is worse than serving a plain JPEG. This single fact explains why no major website has adopted JXL as a primary format, and why that absence of adoption in turn makes it harder to argue for browser support.
The format is also simply too new for the tooling ecosystem to have fully caught up. Photoshop added JXL support only in 2024. GIMP has it behind a plugin. Many CMS platforms have no native JXL pipeline. Automated conversion tools are only beginning to treat it as a first-class output option.
And there is a human element: developers who spent years convincing clients to adopt WebP, then spent more years doing the same for AVIF, are experiencing format fatigue. The question "why not just use AVIF?" is reasonable, and the honest answer, "because JXL is measurably better and will be more universally supported eventually", requires a level of optimism about the future that not every engineering team can afford.
What You Should Do Right Now
The pragmatic answer for most websites in 2026 is to deploy AVIF with a WebP fallback, using <picture> with srcset to serve the right format to each browser. This is the safe, universally compatible, meaningfully better-than-JPEG approach that works today.
<picture>
<source srcset="image.jxl" type="image/jxl">
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description" width="800" height="600">
</picture>Adding JXL as the first <source> in this chain costs you nothing. Safari users get a 50–60% smaller file. Chrome users fall through to AVIF. Older browsers fall through to JPEG. The implementation is additive, you are not removing compatibility, you are extending it.
The more interesting opportunity is for image archives. If you maintain a large library of JPEG files — a photo service, a media company, an e-commerce catalogue, the lossless JPEG-to-JXL transcoding path is worth exploring seriously. You can run the conversion now, serve JXL to Safari users today, and position yourself to serve it to everyone else as browser support expands. The conversion is reversible. The file size savings are immediate for the users who can benefit from them.
The Verdict: Dangerous to Dismiss
JPEG is not going to die this year. It is probably not going to die next year. A format with 34 years of inertia, installed in every camera firmware and embedded in every imaging library on the planet, does not get retired on a schedule anyone can predict.
But the conditions for its replacement have never been better. JPEG XL is genuinely better in every dimension that matters. Apple has committed. Firefox is close. The economic argument for CDNs is compelling. The tooling is maturing. The only thing missing is Chrome, and Chrome's position is not permanent.
The history of image formats on the web is a history of formats that seemed stuck, WebP spent a decade in purgatory before universal adoption arrived almost overnight. The forces driving JXL adoption are more aligned than anything WebP had working for it in its early years.
JPEG will be with us for many more years. But for the first time in three decades, there is something better waiting to replace it, something that has earned that replacement rather than just claimed it. JPEG XL does not need permission to be superior. It only needs time.
