Firefox 158 turns on JPEG XL by default, and puts image/jxl in every image request's Accept header

Firefox 158 reached the release channel on October 13, and its release notes carry one line image-heavy sites will care about: "Firefox now supports the JPEG XL image format, which generally has better compression than WebP, JPEG, PNG, and GIF." The notes give no figures behind "generally."

A pref flipped, not a decoder added

The developer notes on MDN put it more precisely: "Support for the JPEG XL image format (image/jxl) is now enabled by default." The tracking bug, Bug 2065096, is titled "enable image.jxl.enabled pref by default," filed under Core :: Graphics: ImageLib and fixed for the 158 branch.

The code itself has been in shipping builds for six releases. Bug 2016688, "build jpeg xl code on beta/release builds," was fixed for the 152 branch, which compiled JPEG XL into beta and release but left it behind the image.jxl.enabled pref, reachable through the Firefox Labs panel in Settings. In that bug the assignee describes rewriting most of the C++ wrapper code to support progressive rendering (tracked separately as bug 2023488) and plans to fuzz the implementation before it shipped. Bug 2065096 also notes that users who opted in through Labs have to be migrated out of the experiment, work tracked in bug 2074860.

The Accept header is what your server sees

The part a server operator will notice is not the decoder. MDN's HTTP section says the default Accept header for image requests now includes image/jxl, and gives the new value:

image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Sites that choose an image format by reading Accept (an nginx map on $http_accept, a CDN image optimizer, an application that rewrites .jpg to a modern variant) will now see image/jxl from every Firefox 158 user. If that logic already knows about JPEG XL and has a .jxl variant on disk, Firefox starts receiving it. If not, nothing changes, because image/avif and image/webp are still in the list. Anyone serving negotiated images through a shared cache should already send Vary: Accept; with a new type in play, a missing Vary is how one browser's JPEG XL ends up in another browser's response.

What the documents leave open

MDN describes the format, not Firefox's implementation of it:

JPEG XL is a royalty-free raster image format that supports lossy and lossless compression, transparency, animation, and HDR. It can also losslessly transcode existing JPEG images.

MDN, Firefox 158 for developers

Nothing in the release notes, MDN or the enabling bug says which of those features Firefox 158 actually renders, and the enabling bug does not name the decoder library. Animation and HDR in particular deserve a test in the browser before a site relies on them. Until then, the safe deployment is the one negotiation already gives you: offer JPEG XL to clients that ask for it, and keep the AVIF, WebP and JPEG fallbacks for everyone else.

Primary sources: Firefox 158.0 release notes, MDN: Firefox 158 for developers, Bugzilla 2065096, Bugzilla 2016688, read 2026-10-23.