JPEG XL Is in Chrome: What Changes for Your Images, and What Does Not Yet

What Chrome 155 actually shipped

Chrome 155 decodes JPEG XL images on by default, on Windows, macOS, Linux, ChromeOS, Android and Android WebView, with a decoder called jxl-rs that is written entirely in Rust. That is the whole change, and it is the one that matters: a <img src="photo.jxl"> renders in Chrome 155 the way a WebP or AVIF does, with no setting for the user to flip.

The announcement came from the Chrome team on October 6 in a post titled Shipping JPEG XL in Chrome, and the same day's Chrome 155 release notes list "JPEG XL decoding support (image/jxl) in blink". Two details from the post are worth keeping:

• The decoder is new, not the one Chrome removed. The 2021 experiment used libjxl, the C++ reference implementation. Chrome's position since late 2025 was that it would ship JPEG XL only with a memory-safe decoder, because image decoders parse untrusted bytes inside the renderer and have been a reliable source of browser vulnerabilities. jxl-rs is that decoder. Google says fuzzing and code review have found no memory-safety bugs across its history, and that its SIMD layer gets it to roughly the speed of the C++ implementation.

• Google's own advice is "try both". The post recommends testing AVIF and JPEG XL against each other, and says JPEG XL is "most helpful for high-fidelity or lossless compression, especially of photographic images", or where fine-grained progressive loading matters. That is a narrower pitch than "replace everything", and it is the right one.

The timeline, for anyone who lost track:

We covered the February step in Does Chrome 145 Enable JPEG XL by Default?, and the answer to that question is still no. The answer to "does Chrome support JPEG XL" changed on October 6.

JPEG XL browser support, dated October 7, 2026

Three engines decode JPEG XL from mid-October 2026: Chrome from 155, Firefox from 158, and Safari from 17. Each comes with a caveat, and the caveats are different.

Sources: the caniuse JPEG XL table (which records Chrome 155+ and Firefox 158+ as supported and Safari 17+ as partial, with the notes "Supports still images. Animated image sequences are not supported" and "Partial support refers to not supporting progressive decoding"), Chrome's release notes and intent to ship, and Mozilla's Bugzilla entry enabling the image.jxl.enabled preference by default with a target of Firefox 158.

One number to treat carefully: on October 7 caniuse put global support at about 17%, almost all of it Safari. That figure is a snapshot taken the day after Chrome's release and before Firefox's, so it measures installed browsers, not shipping ones. It will climb through October and November as Chrome and Firefox auto-update, and it will stall below the AVIF line until Edge and Samsung Internet move. Quote the date with the number or do not quote it.

Why you still need a fallback, and for how long

You still need a non-JXL fallback for every image you serve on the open web, and you will need it for months, not days. A stable release is the start of a rollout, not the end of one, and three things sit between "Chrome 155 is out" and "my visitors can decode JXL".

Installed versions lag the release. Chrome updates itself in the background, but only when the browser is restarted and only as Google ramps the release across its user base. We checked our own Mac the morning after the announcement and it reported Chrome 152. Enterprise fleets pin versions for longer. For a few weeks, a meaningful share of "Chrome" traffic is Chrome 152, 153 and 154, none of which decode JXL without the flag.

The other Chromium browsers have not moved. Edge, Samsung Internet, Opera, Brave and Vivaldi all inherit Chromium's decoder, but each ships on its own cadence and each can leave a feature off. Edge is the one that matters for desktop traffic, and as of October 7 Microsoft has said nothing. Treat Edge as unsupported until its own release notes say otherwise.

Everything that is not a browser. Email clients render images with their own engines, and none of the big ones have announced JXL. Slack, Notion, Jira and most chat apps show an uploaded .jxl as a broken thumbnail or an undownloadable attachment. Windows still needs an add-on to preview the format. A JXL that renders perfectly in Chrome 155 is still the wrong file to attach to a message.

How long is "months"? Nobody publishes a rollout curve, so here is the honest version: check the caniuse share monthly, and drop the fallback when the browsers your analytics actually show have cleared the version line. For a consumer site in late 2026 that is a question for the new year, not for this quarter.

How to serve JPEG XL safely today

The safe way to serve JPEG XL in October 2026 is the <picture> element with a type attribute per source, JXL first, then AVIF, then WebP, then a JPEG <img> that every client on earth can open. The browser picks the first <source> whose MIME type it can decode and ignores the rest, so a browser that cannot decode JXL never requests the file.

<picture>
  <source type="image/jxl"  srcset="hero.jxl">
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="Describe the image" width="1600" height="900">
</picture>

Three practical notes:

1. Put width and height on the <img>. The fallback image's dimensions reserve the layout box for whichever source wins, which is what keeps your CLS at zero while the browser decides.

2. Do not ship a bare <img src="x.jxl">. On Chrome 152, Edge, and every email client it is a broken image, and a broken LCP image is an LCP failure. This was true last week and it is true this week.

3. Content negotiation is a separate question. Services that pick a format on the server read the Accept request header. Safari has advertised image/jxl there since 17; we could not confirm from Chrome's announcement or release notes whether 155 adds it, so if your CDN negotiates formats, check its documentation for JPEG XL specifically rather than assuming the new Chrome will be served JXL automatically. The <picture> route does not depend on the header at all.

For feature detection in script, decoding a one-pixel JXL data URI and checking naturalWidth is the reliable test; the format-sniffing shortcuts that work for WebP (checking canvas.toDataURL) do not apply, because browsers decode JXL but do not encode it.

Ready to make the JXL variants? Convert a batch to JPEG XL by describing what you want, or go straight to the PNG to JXL converter if the source is PNG.

What JPEG XL gives you that AVIF and WebP do not (and the reverse)

JPEG XL earns its place for lossless work, for high-fidelity photography, for progressive loading and for recompressing existing JPEGs without loss; AVIF stays the stronger choice for ordinary web photos at the file sizes most sites actually serve. Google's advice to try both is not hedging. The formats are good at different things, and the two browser vendors said so in nearly the same words: Mozilla's intent to ship describes JPEG XL as excelling "at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss" and AVIF at "web-quality photographic images".

Where JPEG XL wins:

• Lossless. JPEG XL's lossless mode is the best general-purpose lossless image coder in a browser today. In our screenshot test, one 1440x900 macOS screenshot came out at 1.84 MiB as a PNG and 0.99 MiB as a lossless JXL, a 46% saving with identical pixels. In our six-image lossless benchmark, lossless JXL edged lossless WebP on photographs and lossless AVIF never came first. One caveat from Chrome's own intent-to-ship thread: a reviewer measured the new decoder's lossless path at roughly 30 times slower than WebP's lossless decode on one test image, so for flat graphics that will be viewed in a browser, lossless WebP remains the quicker file to display as well as, in our tests, the smaller one.

• Reversible JPEG recompression. A JPEG can be re-wrapped as a JXL about 20% smaller and converted back to the byte-identical original on demand. No other web format can do this. For an archive of existing JPEGs it is free space with zero risk.

• Progressive decoding. A JXL can render a usable low-resolution image from the first bytes and refine as the rest arrives. Chrome and Firefox decode it progressively; Safari does not. AVIF has no comparable mode.

• Bit depth and gamut. Up to 32 bits per channel, wide gamut and HDR in the format itself. (Note that Firefox currently displays HDR JXL as SDR, and that Mochify's own JXL output is standard range; see the workflow section.)

• Big images. JXL's size limit is over a billion pixels on a side; WebP stops at 16,383.

Where AVIF wins:

• Low and medium bitrates. For a product photo or a blog hero at the quality most sites serve, AVIF usually produces the smaller file. Google's own codec comparisons have AVIF ahead at the bitrates typical of web delivery, and the Chrome blog's "30-50% better than JPEG" figure for JXL is in the same range as AVIF's, not above it.

• Installed base. AVIF has been in Chrome since 85, Firefox since 93 and Safari since 16.4, and it is in Edge and Samsung Internet. For the next several months it reaches more people than JXL by a wide margin.

The practical reading: if you already serve AVIF, you are not behind. Add JXL at the top of the cascade where it is cheaper or where you need lossless or progressive; keep AVIF as the second source; keep WebP and JPEG below that. The decision is covered format by format in WebP, AVIF or JPEG XL in 2026?.

What to do now, by stack

What you should do this month depends on who serves your images, not on the format's merits. Here is the list.

You run a static site or your own build pipeline. Add a JXL variant to your image step and put it first in <picture>. If you encode with cjxl from libjxl, cjxl photo.jpg photo.jxl performs the reversible JPEG transcode by default, and -d 0 gives lossless from any source. If your build uses Node's sharp, check that your installed build includes the JXL codec before relying on it; the prebuilt binaries have historically shipped without it. Or hand the encode to an API: Mochify's POST /v1/squish?type=jxl returns a JXL for any JPEG, PNG, WebP, AVIF, HEIC or SVG you send it.

You use an image CDN. This is where the format arrives with the least work, and where the provider decides. Fastly Image Optimizer accepts format=jxl and its auto mode prioritizes "JPEGXL, AVIF, WebP" in that order. Cloudinary has offered f_jxl since 2020; check its current automatic-format behavior. Cloudflare Images' documented format values are auto, avif, webp, jpeg and baseline-jpeg, with no JXL output at the time of writing. If your CDN cannot produce JXL, nothing changes for you until it can.

You run WordPress. WordPress 7.1's client-side media pipeline decodes HEIC, WebP and AVIF in the browser and outputs JPEG, PNG, WebP, AVIF and GIF; JPEG XL appeared in the June test build's decode list but is in neither list in the release documentation, core has no JXL encoder, and a .jxl upload is still refused because core does not register the MIME type. Keep serving AVIF with WebP and JPEG below it, as in our WordPress next-gen formats guide, and revisit when a plugin or core adds JXL output. You can hand-place a JXL in a <picture> block today, but you cannot make the media library generate one.

You sell on Shopify or a marketplace. Nothing changes. Shopify's accepted upload formats are JPEG, progressive JPEG, PNG, GIF, HEIC and WebP, and its storefront image transforms output JPG, PNG and WebP. A .jxl upload is refused. Our JPEG XL for Shopify answer stands: keep your masters as lossless JXL if you like, upload JPEG or PNG.

You are a photographer or keep an archive. This is the group the release changes most, and the change is not about delivery. Chrome and Firefox decoding JXL means a .jxl sent to a client or a picture editor opens in their browser, where last month it did not. For storage, the lossless JPEG transcode is the move: 20% back on an existing JPEG library with a byte-exact undo, and lossless JXL from RAW-derived TIFFs or PNGs at a fraction of their size. For delivery, keep sending JPEG until the recipient's tools catch up; the format opening in a browser does not mean it opens in Lightroom or an email preview.

You build agent or API pipelines. Add type=jxl as an output option and let the consumer choose. The format is a safe target now because the two browsers your users run will decode it, and the API accepts JXL as input too, so a JXL-in, AVIF-out step costs nothing extra. See how the Mochify MCP server works for the agent surfaces.

Mochify Workflow: converting images to JPEG XL

Every Mochify image surface can output JPEG XL, and the fastest path is to say so in plain English. Here is the workflow for a batch of web images, followed by the other surfaces.

Two honest limits. Mochify's JPG to JXL path is a decode and re-encode, not JXL's reversible JPEG transcode; if you want the byte-exact round trip for an archive, use cjxl, and use Mochify for the web variants. And Mochify's JXL output is standard dynamic range: the HDR gain-map path exists for JPG output only.

Privacy, for this workflow: images travel to api.mochify.app over HTTPS, are encoded in RAM, and are wiped immediately with no disk writes, no logs containing file data, and no use for AI training. That holds for the web app, the CLI, the Chrome extension, the API and both MCP servers; the CLI and local MCP server are clients over the same API and do not encode locally. The hosted MCP server holds the compressed output for up to five minutes on files.mochify.app so the agent can fetch it. The "never leaves your device" line belongs only to Mochify's video tools, which run in the browser.

Cheat Sheet

FAQ