Does Your Browser Support JPEG XL?

The test

Your browser is handed three JPEG XL images embedded in this page — a plain one (97 bytes), one with transparency (175 bytes) and a two-frame animation (88 bytes) — and asked to draw them like any other picture. Each has its own width and height, which the test checks, so a browser can't pass by merely pretending to load them; for the transparent one it also checks that the transparent corner really comes out transparent, and for the animation it asks the browser's own decoder how many frames it reads. Browsers without that decoder interface get the animated square instead, with a note to watch whether it changes colour: we'd rather ask you to look than report a “no” we can't be sure of. If the plain one draws, your browser decodes JPEG XL natively. The test itself fetches nothing and sends nothing: the whole check happens inside your tab.

Natively is the key word. This site's viewer and converter decode JPEG XL with WebAssembly and work in every browser; the test deliberately leaves that out and checks only what your browser can do on its own, which is exactly what decides whether .jxl images on other websites will appear. The answer needs JavaScript, so with it switched off you'll see a short notice instead of the result.

Which browsers support JPEG XL in October 2026

Three engines now show JPEG XL by default: Chrome's since version 155 (6 October 2026), Firefox's since 158 (13 October 2026) and Safari's since 2023. Browsers built on those engines don't always follow them, and Microsoft Edge is the clearest case.

We ran the Chrome, Edge and Brave rows ourselves on Windows 11 on 15 October 2026, with the same method as the test — a tiny JPEG XL image embedded in the page — plus one served over HTTP and a <picture> element with a PNG fallback. Chrome and Brave drew the images and chose the JPEG XL source; Edge failed every check and fell back to the PNG, even when we forced Chromium's JPEG XL feature on from the command line. The other rows come from each browser's release notes, its source code or caniuse.com.

Edge is the surprise. Microsoft listed JPEG XL in its Edge 155 release notes and then removed the entry on 9 October without saying why, and our test agrees with the edit. Opera builds on older Chromium versions than Chrome (Opera 130 used Chromium 146), so, according to caniuse, it has the flag rather than the default. Safari's "partly" means still images only, without progressive loading; and on older Macs it isn't there at all — Apple disabled it on macOS Ventura and Monterey in 2023 because of a rendering bug, and we found nothing saying it came back.

For web developers: how a site can tell

The Accept header. A browser that can decode JPEG XL says so in the Accept header of its image requests. In our test Chrome 155 sent image/jxl,image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8, and Brave did the same; Edge 155 left image/jxl out, and so did Chrome with the feature disabled. Firefox adds image/jxl whenever image.jxl.enabled is on. A server or CDN can use that to decide which file to send.

The <picture> element. Put the JPEG XL in a <source type="image/jxl"> with an ordinary image behind it and each browser takes what it can show. In our test Chrome and Brave downloaded only the .jxl and Edge only the PNG, so nobody wasted a byte.

Decoding, not encoding. None of these browsers can create JPEG XL. In Chrome 155, asking a canvas for image/jxl with toBlob() quietly returned a PNG, which is what the HTML standard says to do with a type the browser doesn't support. Encoding remains a job for cjxl or a converter.

Whatever the test says on your own machine, keep a fallback on a public site. Edge, older Chrome and Firefox, and every browser that simply hasn't updated yet still can't show JPEG XL, and Samsung Internet is unconfirmed. The version you test with is rarely the one all your visitors run.

FAQ