Google Chrome Ships JPEG XL: What It Means for Your Web Images

Google has announced official decoding support for the JPEG XL image format, beginning in Chrome 155. For creators, photographers, and website owners, this marks an important turning point in the long journey toward modern web graphic standards.

The format brings significant improvements over traditional raster files, combining smaller file sizes with high fidelity. Understanding how this release happened and how to handle modern image formats today will help you build faster, cleaner websites without leaving any of your audience behind.

Why JPEG XL Matters for Everyday Creators

According to the Chrome for Developers team, JPEG XL delivers 30% to 50% better compression than traditional JPEG files. It also brings native features that older formats struggle to balance: lossless compression, animated frames, broad color gamuts, and built-in HDR reproduction. Furthermore, JPEG XL allows lossless transcoding of existing JPEG files, meaning photographers can shrink existing archives without degrading visual clarity.

While formats like AVIF already provide strong compression gains on the web, Google notes that JPEG XL is especially beneficial for high-fidelity imagery and photographic content. It also supports progressive decoding, which lets browsers stream and render an image gracefully as it downloads. In contrast, older standards or competing modern codecs can sometimes struggle with seamless progressive previews at high quality settings.

Historically, the Joint Photographic Experts Group, Google, and Cloudinary worked together to develop the JPEG XL standard. Industry brands such as Adobe, Facebook, Intel, Shopify, and Flickr previously expressed strong enthusiasm for the standard. The arrival of native decoding in Chrome brings those theoretical benefits directly to day-to-day web users.

The Technical Turnaround: Memory Safety with Rust

Long-time web observers may remember that Google initially experimented with JPEG XL before removing experimental support in Chrome 110. At the time, the Chrome team cited limited ecosystem interest and a desire to focus on other formats, drawing criticism from developer communities and digital preservationists.

So why did Google change course? A major obstacle for any modern browser is decoder security. As the Chrome engineering team explains, decoders ingest untrusted binary data directly from external networks into renderer processes. Writing these decoders in memory-unsafe languages like C++ historically exposed browsers to severe risks, such as out-of-bounds reads and use-after-free bugs. Mozilla had also previously voiced security hesitations regarding the bulky C++ reference decoder.

To solve this vulnerability, the Chrome team integrated jxl-rs, an independent decoder implementation built completely in Rust. By pairing Rust memory safety guarantees with modern SIMD hardware acceleration, engineers achieved high-speed rendering without introducing memory-safety bugs during development. Furthermore, strong developer interest in the Interop Project encouraged browser makers to collaborate on standardized cross-browser testing for the format in 2026.

Practical Web Strategy: Modern Codecs and Fallbacks

Even with Chrome 155 shipping decoding capabilities, you should never deploy newer image formats in isolation. Browser updates take time to roll out across every device, operating system, and legacy browser. Both Google and MDN Web Docs emphasize using the HTML picture element so older clients can view standard formats safely.

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Landscape view" width="1200" height="800" loading="lazy">
</picture>

By stacking sources in order of efficiency, compatible browsers parse modern formats like JPEG XL or AVIF first. Older devices simply ignore unsupported source tags and display the fallback JPEG or WebP asset without breaking the page layout.

How to Optimize Your Image Workflow Right Now

Until JPEG XL encoding is widely available in all graphics programs, small business owners and creators still need compact, high-performing websites. Preparing your imagery with browser-based tools ensures your site stays lightning-fast and universally compatible.

Step 1: Scale Your Photos to Real Screen Dimensions

Uploading giant camera originals directly to a blog or store is the quickest way to create sluggish pages. Large raster files consume excessive memory on user devices. Before converting or compressing, use the Batch Image Resizer to bring pixel dimensions down to the maximum size your layout requires, such as 1200 pixels or 1920 pixels wide.

Step 2: Convert to Modern Web Formats

WebP and AVIF currently enjoy universal support across all major modern desktop and mobile browsers. Run your high-resolution assets through the Image Format Converter to generate modern WebP or AVIF versions alongside standard JPG fallbacks. This step alone reduces network payload dramatically compared to legacy PNG or JPG files.

Step 3: Run Batch Compression Without Privacy Leaks

Once your dimensions and formats are set, feed the final assets into the Image Compressor. You can fine-tune visual quality to strip unnecessary binary overhead while keeping visual details intact. Because these tools process files entirely inside your web browser, none of your sensitive company photos, client assets, or graphics are uploaded to third-party servers.

Frequently asked questions

What makes JPEG XL different from older JPEG files?

JPEG XL offers 30% to 50% smaller file sizes than traditional JPEG while maintaining equivalent visual fidelity. It also supports modern capabilities like built-in HDR, full lossless compression, animation, and lossless transcoding from existing JPEG data.

Why did Chrome rebuild the JPEG XL decoder in Rust?

Browsers decode untrusted image files directly from external networks, which creates security risks when using memory-unsafe languages like C++. Implementing the decoder in Rust helps eliminate memory safety bugs like heap overflows without giving up hardware performance.

Can I replace all my website images with JPEG XL right now?

Not quite yet. Because older browsers and non-updated devices do not support JPEG XL decoding, you should always serve it inside an HTML picture element alongside fallback formats like WebP, AVIF, or traditional JPEG.

Does JPEG XL replace AVIF and WebP?

Both Google and web performance guidelines recommend experimenting with both AVIF and JPEG XL. JPEG XL is particularly strong for high-fidelity photographs and progressive rendering, while AVIF and WebP remain established modern options with broad browser support.

Sources

1. Shipping JPEG XL in Chrome | Blog | Chrome for Developers (developer.chrome.com)
2. Shipping JPEG XL in Chrome | Blog | Chrome for Developers (developer.chrome.com)
3. Image file type and format guide (developer.mozilla.org)
4. Choose the right image format | Articles | web.dev (web.dev)
5. JPEG XL - Wikipedia (en.wikipedia.org)

How we made this post: we researched the public sources listed above and drafted the article with the help of an AI writing tool (Google Gemini). Automatic checks look for copied wording, numbers that are not in the sources and broken links, but they cannot catch every mistake. Spotted a mistake? Tell us.