JPEG XL Returns to Chrome and Firefox. What Website Owners Need to Know

Key Takeaways

  • JPEG XL is an ISO-standardized image format supporting lossy and lossless compression, HDR, transparency, animation and progressive decoding.
  • Google removed its experimental Chromium implementation in 2022. Chrome 155 brought native decoding back on October 6, 2026.
  • Firefox 158 enabled JPEG XL support by default on October 13, 2026. Safari has supported the format since version 17.
  • The renewed support uses a Rust-based decoder called jxl-rs, addressing some of the security and maintenance concerns associated with the earlier implementation.
  • JPEG XL offers capabilities that can be useful for photographic images, high-fidelity content and existing JPEG archives. It does not automatically outperform AVIF or WebP in every situation.
  • Website owners should test actual image files, preserve browser fallbacks and check their CMS, image-processing and CDN compatibility before adopting the format.

What Is JPEG XL?

JPEG XL, commonly abbreviated as JXL, is a raster image format developed through the JPEG standards process. Its specification is published as the ISO/IEC 18181 series. Files use the .jxl extension and the image/jxl MIME type.

The format supports lossy and lossless compression. It was designed for photographic images, professional image workflows and web delivery, with capabilities that go beyond traditional JPEG.

Its technical specification includes:

  • Lossy and mathematically lossless image compression.
  • Progressive encoding and decoding.
  • High Dynamic Range (HDR).
  • Wide colour gamuts and high bit depths.
  • Transparency through alpha channels.
  • Animation.
  • Image layers, thumbnails and metadata.
  • Reversible transcoding of existing JPEG images.

JPEG XL is therefore more than an alternative file extension for photographs. It provides a broader image coding system that can serve different production and delivery requirements.

The standard consists of four parts covering the core coding system, file format, conformance testing and reference software. The JPEG committee’s current workplan lists ISO/IEC 18181-1:2024, ISO/IEC 18181-2:2026, ISO/IEC 18181-3:2025 and ISO/IEC 18181-4:2022.

What Makes JPEG XL Different?

Several features make JPEG XL relevant to web developers and image professionals. Their practical value depends on the images being processed and the requirements of the publishing system.

Lossy and lossless compression

JPEG XL supports two compression modes. Lossy compression reduces file size by discarding image information. The encoder controls the degree of compression and the resulting visual quality.

Lossless compression preserves the image data exactly. This is useful when exact image reproduction matters, such as in certain editing, storage and archival workflows.

Having both modes in one format gives developers more flexibility when choosing how images should be stored and delivered.

Reversible JPEG transcoding

One of JPEG XL’s more distinctive features is its ability to preserve an existing JPEG in a form that allows the original file to be reconstructed exactly.

A JPEG image can be transcoded into JPEG XL using lossless JPEG recompression. The resulting JXL file contains the information necessary to reconstruct the original JPEG, including its original encoded image data and associated metadata.

This is different from opening a JPEG, decoding it and saving it again using another lossy compression setting.

The practical advantage is storage and migration flexibility. A service managing a large JPEG archive can potentially store one JXL representation and reconstruct the original JPEG when a client or application requires it.

The JPEG committee specifically identifies this capability as a way to make migration from existing JPEG systems easier.

Progressive decoding

JPEG XL supports progressive decoding. The decoder can display an initial representation of an image while additional image data is still downloading.

This can improve perceived loading behaviour, particularly for large photographs and slower connections. Visitors may see an initial version before the complete image has arrived.

The actual benefit depends on the image, encoder settings, decoder implementation and delivery conditions. Smaller files do not automatically guarantee a noticeable improvement in every page-loading scenario.

HDR, colour and transparency

JPEG XL supports HDR images, wide colour gamuts and high bit-depth data. These features are relevant to professional photography, image editing and display workflows that require more colour or brightness information than a conventional 8-bit sRGB image can represent.

It also supports alpha transparency and animation. This allows the format to be used for content beyond conventional static photographs.

Why Google Removed JPEG XL in 2022

JPEG XL is not a new format introduced in October 2026. Chromium first experimented with decoding support in 2021, initially making it available behind a feature flag.

Google subsequently decided to remove the implementation. The change was announced in November 2022 and targeted for Chrome 110.

The decision reflected several considerations discussed by the Chromium team.

In its November 11, 2022 communication on the Chromium developer mailing list, Google engineer Jim Bankoski explained that each additional image format creates costs for browser and device partners. The evaluation considered compression performance across different images, decoder speed, encoder availability, hardware support, existing alternatives and adoption by other browsers and operating systems.

The team decided to end the experiment and remove its associated code.

The stated reasoning was therefore about the overall benefits and costs of maintaining another browser image format. It should not be interpreted as evidence that JPEG XL was technically defective.

The removal also demonstrated a practical difficulty for new web standards. A format can offer useful technical capabilities and still struggle to gain adoption when browser vendors, operating systems, content delivery networks and creative applications do not support it consistently.

Why Chrome and Firefox Have Brought It Back

The renewed interest in JPEG XL is the result of work on browser implementation, decoder security, performance and interoperability.

The earlier Chromium implementation relied on the C++ libjxl decoder. Although the library is an established reference implementation, handling complex image data in a browser introduces security considerations.

Image decoders process files that may come from untrusted external sources. Bugs involving memory handling can create vulnerabilities, making decoder architecture and maintenance important parts of browser development.

The Rust-based decoder

Google and contributors to the JPEG XL project developed jxl-rs, a decoder written in Rust.

Mozilla explained its position in an August 2026 announcement. Its earlier experimental implementation had raised concerns about the attack surface associated with a large, multithreaded C++ decoder. Mozilla subsequently supported shipping JPEG XL with a Rust-based implementation that could meet its requirements for security, performance and compatibility.

The new decoder uses Rust’s memory-safety features to reduce certain classes of programming errors. This does not make it immune to vulnerabilities, but it changes the implementation’s approach to memory management.

Both Google Chrome and Mozilla Firefox now use jxl-rs for JPEG XL decoding.

It is important to distinguish the two projects:

  • libjxl is the JPEG XL project’s C++ reference implementation.
  • jxl-rs is a separate Rust implementation used by Chrome and Firefox.

Chrome 155 enables JPEG XL by default

On October 6, 2026, Google announced that Chrome 155 would ship JPEG XL decoding support.

The announcement identified developer feedback and work through Interop 2026 as important factors in the decision. The Interop investigation focused on making browser implementations more consistent and improving test coverage for JPEG XL features.

Google also stated that JPEG XL can provide 30–50% better compression than JPEG. This figure should be understood as Google’s reported comparison, not a guaranteed reduction for every image.

The Chrome team recommends testing both AVIF and JPEG XL to determine which produces the best result for a particular use case. It identifies JPEG XL as particularly relevant to high-fidelity and lossless compression, photographic images and applications that benefit from progressive decoding.

Firefox 158 follows

Mozilla enabled JPEG XL by default in Firefox 158, released on October 13, 2026. The release also added image/jxl to Firefox’s default HTTP Accept header for image requests.

This matters for websites that use server-side content negotiation. A server can inspect the formats a browser advertises and select an appropriate image representation.

Which Browsers Support JPEG XL in 2026?

As of October 31, 2026, JPEG XL support is available in several major browser implementations, but compatibility information is not completely consistent.

BrowserVersionSupport
Google Chrome155 and laterEnabled by default
Mozilla Firefox158 and laterEnabled by default
Apple Safari17 and laterSupports JPEG XL decoding
Microsoft Edge155 and laterCompatibility references differ

There is a specific discrepancy regarding Edge. MDN lists Edge 155 as supporting JPEG XL, while Microsoft’s 2026 web-platform dashboard still reports that the feature is not fully supported in Edge. Website owners should test the actual stable Edge versions used by their audience instead of assuming complete compatibility.

Safari has supported JPEG XL since Safari 17, released in September 2023. Its implementation does not offer identical progressive-rendering behaviour to the newer Chrome and Firefox implementations, so progressive delivery should also be tested separately.

JPEG XL vs JPEG, WebP and AVIF

JPEG XL overlaps with existing image formats, but the formats have different capabilities and compatibility histories.

FormatCompressionTransparencyAnimationHDRProgressive decoding
JPEGLossyNoNoNoYes, progressive JPEG
WebPLossy and losslessYesYesYesNo
AVIFLossy and losslessYesYesYesNo
JPEG XLLossy and losslessYesYesYesYes

The table summarizes format capabilities. Specific implementation support can vary by browser and software version.

JPEG remains widely compatible and is still a practical fallback. WebP and AVIF are already established options for modern web image delivery.

JPEG XL adds several capabilities that may be useful in specific workflows, especially reversible JPEG transcoding, progressive decoding and high-fidelity image representation.

There is no universal compression winner. The result depends on the image, encoder, settings and required visual quality.

For example, a photograph may produce a different file-size comparison from a screenshot containing text, a transparent product image or a detailed illustration. The amount of acceptable information loss also changes the result.

Google’s recommendation to test AVIF and JPEG XL is therefore sensible. Format selection should follow measured results rather than a general assumption that one newer format must always be better.

What Website Owners Should Consider

The renewed browser support makes JPEG XL worth evaluating, but it does not mean existing image libraries should immediately be converted.

Website owners need to consider the entire image-delivery process, including content management systems, image optimization tools, CDN configuration and browser compatibility.

Provide fallback formats

The HTML <picture> element allows a website to offer several image formats. The browser selects the first compatible source and uses the <img> element as the fallback.

<picture>
  <source srcset="/images/product.jxl" type="image/jxl">
  <source srcset="/images/product.avif" type="image/avif">
  <source srcset="/images/product.webp" type="image/webp">
  <img
    src="/images/product.jpg"
    alt="Product description"
    width="1200"
    height="800"
  >
</picture>

This approach allows a website to offer JPEG XL without requiring every visitor to have a compatible browser. The order of the sources should reflect the formats you intend to prioritize. The final remains necessary because it supplies the fallback and the image’s descriptive attributes.

Test image compression with your actual content

Do not rely solely on advertised compression percentages. Select representative images from the website and encode them with JPEG XL, AVIF and WebP. Compare the results at equivalent visual quality settings.

Useful test categories include:

  • Product photographs.
  • Large editorial photographs.
  • Transparent product images.
  • Screenshots and interface graphics.
  • Images containing text or fine lines.
  • High-resolution photographs requiring careful colour reproduction.

Record file size, visual differences, encoding time and decoding behaviour. For lossless workflows, verify that the decoded output is identical to the source. This will show whether JPEG XL offers a practical benefit for the website’s actual content.

Check CMS and image-processing compatibility

Browser decoding is only one part of the workflow.

A website’s image format may pass through several systems before a visitor sees it:

  1. Original image upload.
  2. Image processing and resizing.
  3. CMS storage and media management.
  4. Optimization or conversion plugins.
  5. CDN delivery and caching.
  6. Browser decoding.

If any component cannot process JPEG XL correctly, the format may introduce problems even when the visitor’s browser supports it.

Before changing an image pipeline, check whether the CMS, hosting environment, image optimization service and CDN can store, generate, serve and cache JXL files correctly.

Consider HTTP content negotiation and caching

Firefox 158 now advertises image/jxl in its default image-request Accept header. A server can use this information to select an image representation. However, dynamic format negotiation requires correct caching configuration.

When the server returns different image formats according to the Accept header, the response should include an appropriate Vary: Accept header. This tells caches that the representation depends on the request’s accepted content types.

Without correct cache variation, a CDN or intermediary cache could serve an image representation intended for a different browser capability.

References: MDN: Accept Header and MDN: Vary Header.

Measure the effect on website performance

Smaller image files can reduce transfer sizes. That is useful, but file size alone does not determine page performance.

Measure the impact on real pages, including:

  • Image transfer size.
  • Loading and rendering behaviour.
  • Largest Contentful Paint (LCP).
  • Caching efficiency.
  • Image decoding behaviour on mobile devices.
  • Any additional processing required by the server.

A format change should be retained when it produces a measurable benefit without introducing compatibility or workflow problems.

Should You Start Using JPEG XL?

JPEG XL is now a practical option for websites using compatible browsers. The renewed support in Chrome and Firefox removes one of the main adoption barriers that existed after Google’s 2022 decision.

However, the format still belongs alongside existing options rather than replacing them automatically.

It is particularly worth evaluating for:

  • Large photographic image collections.
  • Workflows that require lossless compression.
  • Existing JPEG archives where reversible transcoding may reduce storage requirements.
  • High-resolution images that benefit from progressive decoding.
  • HDR and wide-colour-gamut image delivery.

A website with an established AVIF or WebP pipeline may see little reason to change immediately. The decision should depend on actual compression results, browser coverage and the capabilities of the publishing system.

JPEG XL’s return also illustrates a broader point about web standards. A technical specification alone does not guarantee adoption. Browser implementations, security reviews, testing, developer demand and supporting software all influence whether a format becomes practical to use.

For website owners, the next step is straightforward: test JPEG XL with real content, compare it with the formats already in use and retain fallbacks until compatibility is sufficiently reliable for the intended audience.

Resources

Standards and technical documentation

Browser announcements and compatibility

Supporting ecosystem

Playful Sparkle has been engineering robust digital ecosystems since 2004. Our services include SEO & Digital Marketing, Web Development, and Branding & Strategy. Image delivery is one part of website engineering. Choosing a format requires consideration of browser support, the publishing workflow, server configuration and measurable performance. Explore our Web Development services or contact Playful Sparkle to discuss your project.

Was this helpful - Post
Add playfulsparkle.com as a preferred source on Google
Zsolt Oroszlány

Zsolt Oroszlány

Founder & Chief Creative Officer of Playful Sparkle since 2004, combining business leadership, digital strategy, design, and software engineering to help organizations build effective digital solutions. Regularly publishes insights on web development, SEO, design, and emerging technologies.

More Insights

NIS2 in Slovakia and What It Means for Your Business

NIS2 applicability in Slovakia depends on an organisation’s actual activities, company size and specific statutory inclusion criteria. Learn how to assess your regulatory status, notify the NBÚ, implement cybersecurity measures, report serious incidents and meet audit or self-assessment requirements.