JPEG XL Is Reaching the Web. Here's What That Changes
For years, JPEG XL has lived in an awkward spot: it's technically interesting, but it hasn't had the browser support you need for it to be a no-brainer on the open web. That could be changing. Reports from October 2026 say JPEG XL support is starting to land in both Google Chrome and Mozilla Firefox, which removes a major reason teams have avoided deploying it directly in browsers.
Still, browser support alone doesn't mean every site should swap formats overnight. Even after a format works in a browser, you have to think about device coverage, your image pipeline, encoding time, visual results, and what happens when a visitor's browser can't handle it. JPEG XL also has competition - AVIF already has solid browser support, and depending on the content it can deliver noticeably smaller lossy images.
So the real question isn't "Is JPEG XL the winner?" It's whether it performs well for your workloads, whether it simplifies your delivery stack, and whether the payoff is worth adding another format to the mix. This guide breaks down what JPEG XL is, compares it with AVIF, and shows a practical way to test it without turning your production site into a science project.
What Browser Support Changes
A new image format can look great on paper and still be a headache for most websites. If a meaningful share of visitors can't render it, teams end up generating fallbacks, maintaining more assets, and building more complicated format-selection logic. In practice, that operational cost often eats the value of smaller files.
That's why the reports about JPEG XL support in Chrome and Firefox matter. They suggest the format is moving from niche workflows into something closer to mainstream browser delivery. But that's not the same as proving support is available everywhere you care about - every stable browser version, every platform, and in every part of your image-processing chain. Support can vary by version, rollout timing, and platform.
Before you change production, check the current situation on Can I Use and test the browser versions your audience actually uses. The adoption chart in the original announcement is helpful background, but a global percentage won't tell you what matters for your users.
Support is the start, not the finish line
Even after a browser adds support, you still have a bunch of practical questions:
- Which browser versions do your customers actually use?
- Can your CMS or image CDN accept and serve JPEG XL?
- Can your build pipeline encode it reliably at the quality settings you want?
- Does it improve the experience enough to justify extra files or extra processing?
- What happens when a visitor's browser can't display it?
"Supported" doesn't guarantee "works" in production. It can fail if your CMS strips file extensions, a proxy returns the wrong content type, or your pipeline silently converts the image. Test the whole path - from the source asset through the CDN response to what the browser renders - rather than relying on a quick local file test.
For teams, the point of this news is simple: JPEG XL is becoming easier to evaluate. It's not a signal to treat AVIF, WebP, or JPEG as obsolete. Browser support reduces adoption risk, but you still need to measure results.
A format transition takes time
Web image formats rarely replace each other cleanly. JPEG stays popular because it's reliable and supported almost everywhere. PNG still matters for lossless graphics and transparency. WebP and AVIF have found their lanes for specific delivery needs. A new format joins an ecosystem that already works, and your tooling and delivery behavior don't automatically update themselves.
The sensible approach is incremental: keep your fallback, introduce JPEG XL for a defined set of assets, and watch what happens. That way you're collecting real evidence instead of betting your whole image stack on a browser-support announcement.
What JPEG XL Does Differently
JPEG XL is built to cover several image needs in one format. It supports lossy and lossless compression, transparency, animation, progressive decoding, and high bit-depth imagery. That range is useful, but it's not as simple as "one extension replaces everything." The real value is that it can handle different kinds of image data without forcing every use case into the same trade-offs.
For most web photography, the usual evaluation criteria still apply: visual quality, file size, decoding performance, and compatibility. JPEG XL can be competitive on compression, but results depend on the input images, encoder choices, and the quality targets you use. A small test on a few photos won't automatically tell you what will happen across product images, illustrations, screenshots, and user uploads.
One format for more than photographs
JPEG XL covers features that often live across multiple formats today:
- Lossy and lossless images: Useful for delivery and preservation workflows.
- Transparency: Helpful for logos, overlays, and graphics that need an alpha channel.
- Animation: It can represent variable-frame animations as an alternative to animated GIF or WebP in the right workflows.
- Progressive presentation: Support for progressive decoding can help in some delivery scenarios.
- High bit depth and wide color: Useful for professional imagery and workflows beyond standard 8-bit output.
That broader feature set can make an asset library easier to manage - especially for teams dealing with photography, archival masters, and high-bit-depth sources. But consolidating formats doesn't automatically reduce operational work. If your tools, browser support assumptions, and CDN setup were built around JPEG, PNG, WebP, and AVIF, switching will take some pipeline work before it actually simplifies anything.
Lossless JPEG transcoding is a distinct advantage
One of JPEG XL's standout capabilities is lossless recompression of existing JPEGs. In supported workflows, you can convert a JPEG to JPEG XL while preserving enough information to reconstruct the original JPEG bit-for-bit. The resulting JPEG XL file can be smaller - often cited around 20% in some cases - without turning the process into "another lossy generation."
This is different from decoding a JPEG into pixels and then re-encoding them into a new lossy output. Re-encoding can change the image and introduce additional generation loss. Lossless JPEG transcoding aims to preserve the original JPEG representation, which is particularly relevant for archives and large collections where keeping the source matters.
Savings won't show up for every file, and the outcome depends on the source and encoding process. Also, this doesn't mean you should convert your entire library. It's most worth testing when you manage a large archive, need to retain original JPEGs, or want a reversible way to reduce storage. For regular web delivery, compare the full cost: conversion time, storage, serving overhead, and fallback behavior.
High bit depth and HDR need real workflow support
JPEG XL can represent high-bit-depth and wide-gamut image data, including floating-point HDR workflows. That makes it relevant beyond standard web photography - think professional masters, gradients where banding isn't acceptable, or image data with extra channels.
But storing HDR data doesn't guarantee the same HDR results across browsers and devices. Display support, color management, and browser handling all affect what visitors actually see. The source material notes that browser support for gain maps is still developing. In other words: test the full path on real target devices before treating JPEG XL as a turnkey HDR delivery solution.
JPEG XL vs. AVIF: Choose by Workload
AVIF isn't obsolete just because JPEG XL is getting browser support. AVIF is based on intra-frame coding from AV1, is royalty-free, and already has broad browser adoption. For lossy web images, it's usually a strong default - and on some image sets it can produce smaller files than JPEG XL at comparable visual quality.
JPEG XL has a different set of strengths. It supports both lossy and lossless modes, handles a wide range of image features, and offers the reversible JPEG transcoding capability discussed above. In the source material's comparison, JPEG XL comes out stronger for lossless compression, while AVIF tends to win on lossy file size. Neither result is guaranteed. Outcomes depend on content, encoder settings, and how you define "comparable quality."
Compare on your own images
If your site is mostly product photography, your AVIF results may already be excellent. If you manage design assets with transparency, high-quality source files, or a large JPEG archive, JPEG XL may be a better fit to test. If users upload images, base your comparison on representative uploads - not just carefully curated test images.
A good comparison set includes:
- Photographs with fine texture (hair, foliage, fabric).
- Images with gradients (where banding shows up).
- Screenshots and graphics (sharp edges and text).
- Transparent assets (if you serve them).
- High-resolution source files and real user uploads.
For each format, compare visual quality at a target file size and file size at a quality level you'd be comfortable shipping. Also measure decode time and what that does to page performance. A smaller file isn't automatically a faster experience if it decodes more slowly on the devices your visitors use.
The source notes that AVIF can have an edge on raw decode speed in some comparisons, while JPEG XL decoding uses modern CPU features like SIMD. That's a reason to benchmark, not a cue to rank everything ahead of time. Results vary with implementation, hardware, and image characteristics. Hardware acceleration for JPEG XL is discussed as a future possibility, not something you should assume in today's performance model.
A practical decision table
| Situation | First format to test | Why |
|---|---|---|
| Lossy web photography | AVIF and JPEG XL | Compare size and quality on real images |
| Existing JPEG archive | JPEG XL | Reversible JPEG transcoding may reduce storage |
| Lossless image delivery | JPEG XL and PNG | Compare size, compatibility, and workflow support |
| Broad compatibility requirement | JPEG or WebP fallback | Established support still matters |
| High-bit-depth or HDR workflow | JPEG XL, with device testing | Feature support doesn't guarantee consistent display |
This isn't a universal performance table. It's a starting point for deciding what's worth testing. Keep AVIF in your mix where it performs well, and don't pick a format based on one benchmark or one convenient image.
How to Evaluate JPEG XL in Production
If you want the lowest-risk path, make the decision measurable and reversible. You don't need to convert everything to learn whether JPEG XL helps. Start with a defined slice of traffic or a category of images, and compare it to your current delivery setup.
Step 1: Check browser and tool support
Confirm support for the browsers and devices your audience actually uses. Then verify that your encoder, build tools, CMS, CDN, and monitoring setup can handle JPEG XL correctly. If it works in a desktop browser but breaks in your image transformation service, it's not ready for production.
For Photoshop users, the source material notes that older versions - CS6 through 26.7, before the June 2025 release - may require a plugin for import and export. One option is the open-source JPEG XL Photoshop plugin. Still, confirm compatibility with your specific Photoshop version and workflow before betting on it; details can change over time.
Step 2: Create a representative test set
Use images from your actual site, not just sample files from format comparison articles. Include the assets that cause problems today: large photography, fine-detail images, transparent graphics, gradients, and user uploads. Track the original file, encoder version, settings, output size, and any visible quality issues.
If you're testing archival conversion, keep originals until you've verified the converted files can be read and - when relevant - reconstructed as expected. A "looks fine" test on a handful of files isn't enough to justify an irreversible bulk change.
Step 3: Measure the whole delivery experience
Don't stop at average file size. Useful measurements include:
- Bytes transferred per page (or per image category).
- Image decode time on representative devices.
- Page performance and perceived loading behavior.
- Conversion cost and processing time.
- Cache hit rates and CDN behavior.
- Failure rates and fallback usage.
A 10% reduction in image bytes can be worth it for a high-traffic site, but it's less meaningful if it adds expensive encoding time or makes your build pipeline brittle. Treat the decision as part of an ongoing system: generating, storing, serving, and debugging the format.
Step 4: Roll out with a fallback
Serve JPEG XL only when the requesting browser can handle it, using content negotiation or your image platform's supported format selection. Keep a fallback for browsers that can't. Test the actual HTTP response too - content type, caching behavior, and how your CDN chooses a variant.
Start small. Compare real user performance, errors, and image quality against a control group (or the previous format). If the improvement shows up and the pipeline stays stable, expand gradually. If it doesn't, keep JPEG XL limited to the workflows where it clearly delivers value instead of forcing a site-wide migration.
That's the difference between adopting capability and chasing a format. The first improves your system; the second adds moving parts without earning the change.
Conclusion
JPEG XL arriving in Chrome and Firefox is meaningful because browser support has been one of the biggest blockers to practical adoption on the open web. The format brings a broad feature set, high-bit-depth capabilities, and a way to shrink existing JPEG archives without going fully lossy.
Those are real advantages - especially for teams with demanding image workflows. But it doesn't make AVIF irrelevant, and it's not a reason to do an automatic, site-wide conversion. Test against your content, measure the full delivery path, and keep fallbacks while support and tooling mature. If JPEG XL makes a specific part of your system smaller, more reliable, or easier to preserve, roll it out there first.
Start with a representative image set and a small production test. Let the results - not the announcement - decide what you serve.