Firefox 158 ships with JPEG XL enabled by default
Firefox 158 ships October 13, 2026 with JPEG XL (image/jxl) enabled by default and image/jxl in the Accept header, a week after Chrome 155.
Firefox 158, the newest release of Mozilla’s Gecko browser, started rolling out on October 13, 2026 at 13:00 UTC with an initial 25% rollout. The change worth your attention sits in the image pipeline: JPEG XL (image/jxl) is enabled by default for the first time, and the browser’s default Accept header for image requests now offers image/jxl — the step that finally lets a server negotiate the format. Per MDN’s developer release notes, the same version adds CSS typed arithmetic, letting calc() divide two values of the same data type even when their units differ.
Key points
- Firefox 158 began shipping on 2026-10-13 at 13:00 UTC (6 AM Pacific) with an initial 25% rollout; the first dot release is scheduled for October 20.
- The JPEG XL decoder is now on by default: Bugzilla bug 2065096 (“enable image.jxl.enabled pref by default”) is marked RESOLVED FIXED against milestone 158 Branch, and the default image Accept header became
image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5. - One week earlier, on October 6, Chrome’s blog confirmed JPEG XL shipped in Chrome 155; Safari has supported still JXL images only since 17.0, and Edge has no support yet.
Background
JPEG XL landing in Firefox took one release longer than planned. Until now the format sat behind a flag: per caniuse data, Firefox 153 through 157 shipped it on by default only on Nightly, other channels needed the image.jxl.enabled switch in about:config, and 152 had no channel default at all — what Phoronix described as “gated by an experimental option.” In late August, Mozilla’s shipping plan still pointed at 157: Phoronix’s related coverage at the time was titled around Mozilla’s plan to ship JPEG-XL in Firefox 157. Yet the official 157.0 release notes, published September 29, contain no JXL entry at all; the plan slipped to 158.
The actual flip is documented on Bugzilla: bug 2065096, filed by Timothy Nikkel, is marked RESOLVED FIXED with the 158 Branch as its target milestone. In the comments he requested a release note with the wording “The JPEG XL image decoder is now enabled by default in Firefox” and noted Firefox for Android is affected too. Engineer Beth Rennie raised the follow-up of migrating users out of Firefox Labs so the experiment stops appearing in settings once the lab is paused.
The competitor moved first: Chrome’s blog post “Shipping JPEG XL in Chrome” on October 6 confirmed the format ships in Chrome 155, with the decoder rewritten in Rust (jxl-rs) and a rationale of “consistent feedback and requests from web developers.” Firefox 158 arrives a week after the Chromium side switched its default on.
The facts
The release parameters and the JXL switch trace to Mozilla’s release calendar, MDN and Bugzilla:
| Item | Value | Source |
|---|---|---|
| Rollout start | 2026-10-13, 13:00 UTC (6 AM PT) | official release calendar |
| Initial rollout | 25% of users | official release calendar |
| Dot release 1 | October 20 | official release calendar |
| Preference | image.jxl.enabled defaults to true | Bugzilla 2065096 |
| Scope | Desktop and Android | Bugzilla 2065096 comments |
The default Accept header for image requests is now (MDN, bug 2065096):
image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
MDN describes JPEG XL as a royalty-free raster format supporting lossy and lossless compression, transparency, animation and HDR, which can also losslessly transcode existing JPEG images. The typed arithmetic landing in the same release (bug 2067411) lets calc() divide two same-type values with different units and convert the unitless quotient to other types. Phoronix also lists Smart Window form filling among this release’s changes.
Where browsers stand (caniuse jpegxl data, checked 2026-10-13):
| Browser | JPEG XL status |
|---|---|
| Firefox 158+ | enabled by default |
| Chrome 155+ | enabled by default (flag-only for 145–154) |
| Safari 17+ | partial: still images only, no animation or progressive decoding |
| Edge | not supported |
Two date caveats: Mozilla’s user-facing release notes were still a placeholder as of October 13 (“We’re still preparing the notes”), and Phoronix’s story ran on October 12, ahead of the official rollout time.
What others say
Michael Larabel’s Phoronix report on October 12 led with the JXL default and recalled the flag-gated history of prior releases. Mozilla’s side of the story lives on Bugzilla: filer Timothy Nikkel proposed the “decoder is now enabled by default” release-note wording, while Beth Rennie focused on closing out the Firefox Labs experiment for existing users. Chrome made its motive explicit: “Our decision to ship JPEG XL was based on consistent feedback and requests from web developers,” alongside a claim of 30–50% better compression than JPEG — a vendor figure, not an independent benchmark.
Community traffic is thin so far: the Phoronix story hit Hacker News on October 12 and stood at 8 points with 0 comments as of publication (October 13). Chinese coverage landed the same evening: IT Home’s October 12 report (published 23:19) headlined Firefox 158 shipping with JPEG XL enabled by default — also ahead of the official rollout time. When a format its advocates championed for years finally ships by default, the quiet is telling — AVIF filled the gap while JXL was out.
Pipeline impact
For teams serving images, the change breaks down three ways. Negotiation: servers reading the Accept header can now identify image/jxl-capable clients — Firefox 158 and Chrome 155 both qualify — so returning JXL is technically viable. Migration: per MDN, existing JPEGs transcode to JXL losslessly, so an archive can shrink without touching pixels; to experiment locally first, a no-upload desktop converter like convt batch-converts formats on-device. Compatibility: Safari only handles still JXL and Edge doesn’t decode it at all, so Accept-header switching still needs an AVIF/WebP or PNG fallback for those clients. Photography and editing workflows have the most format sensitivity — our LightCraft hands-on (LightCraft) covered where raw color calibration still falls short — and JXL’s real-world payoff there depends on tooling catching up.
Our take
Who should care: anyone running an image-heavy site (bandwidth is a real cost line; Chrome’s 30–50% figure is worth measuring yourself before it goes into a budget), anyone maintaining a large photo library (lossless transcoding means migration without pixel loss), and front-end authors of design systems (typed arithmetic finally lets calc() express the ratio of two values). The honest catches: the 25% stagger means a version check today may still report 157; with Safari and Edge uncovered, serving JXL-only is still not an option on any public site; and the user-facing release notes were still a placeholder at publish time, so MDN and Bugzilla are the only citable sources. What to watch: the October 20 dot release and rollout progress, Mozilla’s final notes, and whether Edge follows — caniuse still marks Edge as unsupported, and nobody on the Chromium side has committed to a date.