Will JPEG XL finally get full browser support by 2027?

The Short Answer

As of August 2026, the honest answer is: partial support is here, but full universal support is still not guaranteed for 2027. Safari has supported JPEG XL natively since version 16.4 (March 2023), Firefox enabled it by default in stable releases starting in late 2024, and Chromium-based browsers — Chrome, Edge, Brave, Opera — remain the holdout. Google removed its experimental JPEG XL flag in Chrome 110 in early 2023 and has shown no public commitment to re-enabling it. Whether 2027 brings a reversal depends on factors that have nothing to do with image quality: codec politics, patent positioning, and whether enough of the web ships .jxl files to make ignoring them costly.

Also worth reading: What are the best digital payments guides and tools for consumers and small businesses in 2026? · How do stablecoin payment workflows actually work in 2026, and what should merchants and consumers know before using them? · What are the most important digital payment workflows to know in 2026?

So if you are planning a website or an asset pipeline around JPEG XL in 2026, you should treat it as an enhancement, not a baseline. Roughly speaking, somewhere between 30 and 45 percent of global browser traffic can decode JPEG XL today depending on your audience mix, because Safari plus Firefox covers iOS/macOS users and a meaningful slice of desktop users, while Android's dominant Chrome engine does not.

How We Got Here: A Brief Timeline

JPEG XL was standardized by the Joint Photographic Experts Group in 2021 as ISO/IEC 18181. It promised two things the industry wanted: roughly 35 to 60 percent smaller files than JPEG at equivalent visual quality, and lossless recompression of existing JPEGs at about 20 percent smaller with zero quality loss. Apple shipped support in Safari 16.4 in March 2023. Google had an experimental flag behind --enable-features=JXL but removed the code entirely in Chrome 110 (February 2023), citing insufficient ecosystem interest and maintenance costs.

Mozilla took a more measured path. JPEG XL lived behind the image.jxl.enabled flag in Firefox for years, with engineers citing concerns about the reference decoder's size, memory safety, and fuzzing maturity. By Firefox 133 in November 2024, the feature was enabled by default on desktop builds, following sustained work on hardening the libjxl integration. Linux distributions have also played a role: recent Ubuntu releases ship GTK tooling and document viewers with JPEG XL decoding built in, and camera-adjacent software increasingly handles the format alongside raw workflows.

The result in mid-2026 is a split web: one rendering engine family (Gecko) and one platform vendor (Apple) say yes, and the largest engine family says no.

Why Chrome Still Says No

Google's stated reasons have been consistent since 2022 and 2023. First, the Chrome team argued there was no evidence of meaningful web adoption — few sites served .jxl, so supporting it added binary size and attack surface for little user benefit. Second, Google was heavily invested in AVIF, which shares infrastructure with its video codecs and covers both still images and animation. Third, the reference libjxl implementation was large relative to other image decoders, raising memory-safety and supply-chain concerns that Mozilla spent years addressing before enabling it.

Critics counter that this is circular reasoning: sites will not adopt a format browsers refuse to render, and browsers refuse to render a format sites do not use. That deadlock is exactly why the 2027 question matters. For the logjam to break, one of three things must happen: Google reverses course under competitive pressure, a major content platform ships JPEG XL at scale forcing universal client support, or the format quietly becomes a niche professional format like WebP's early years. As of August 2026, none of those triggers has fired decisively, though the growing list of hardware encoders, camera firmware mentions, and OS-level decoders keeps pressure on.

Current Support Matrix (August 2026)

Read that table carefully and you see the practical picture: Apple's entire installed base plus Firefox users gives you real coverage, but any Chromium-based strategy — which is most of Windows and effectively all of Android — fails without a fallback.

Practical Steps If You Want to Use JPEG XL Today

If you run a website, the safe pattern is content negotiation or dual encoding. Serve AVIF or WebP as the fallback inside a <picture> element and offer .jxl first for capable clients. Tools like Squoosh, libjxl's cjxl command-line encoder, and various build plugins make generating all three variants a one-time pipeline step rather than ongoing labor. Expect JPEG XL to win on file size against both alternatives in most photographic tests — commonly 20 to 40 percent smaller than AVIF at high quality settings, with dramatically faster encode times than AVIF's, often 5 to 10x quicker per image.

For personal archives, the calculus is different and more favorable. Recompressing an old JPEG library losslessly with cjxl -d 0 typically shrinks files about 20 percent with bit-exact reversibility via djxl. Because the format is an ISO standard with multiple independent implementations underway, the archival risk is lower than the browser-support drama suggests. Keep original JPEGs if you are paranoid, but JXL is now a reasonable primary format for new photo libraries, especially given fast lossless transcode back out.

For merchants and payment-platform teams — relevant if you manage checkout pages where every kilobyte affects conversion — the guidance is blunt: do not gate critical product imagery behind JPEG XL alone. Checkout flows already juggle 3-D Secure redirects, wallet SDKs, and third-party scripts; adding a format that breaks for half your Android traffic is self-inflicted harm. Use it as a progressive enhancement where the savings compound across thousands of catalog images.

Comparison: JPEG XL vs the Alternatives

The table explains the strategic tension well. AVIF won the compatibility war but loses badly on encoding cost at scale — a real problem for platforms processing millions of images. JPEG XL wins on speed, quality-per-byte, and backward compatibility with legacy JPEG, but loses on reach. WebP remains the boring, safe default that nobody gets fired for choosing.

Common Mistakes People Make Right Now

The most frequent error is assuming Firefox support means the problem is solved. Firefox desktop plus Safari is a minority coalition; Chrome on Android alone represents more traffic than both combined in most analytics reports. Shipping .jxl without a <picture> fallback produces broken images for the majority of mobile visitors, which is worse than never adopting the format.

A second mistake is confusing OS-level support with browser support. Windows 11, recent macOS versions, and modern Linux desktops can display .jxl files in file managers and photo apps, and camera vendors have begun advertising JPEG XL output modes in firmware changelogs alongside raw-format improvements. None of that helps a Chrome tab. Users regularly conclude "my computer opens these fine" and then cannot understand why their website visitors see nothing.

Third, some site owners rely on browser extensions or polyfills to justify adoption. Extensions help individual enthusiasts, not audiences — you cannot ask customers to install software to view your product photos. Finally, people over-index on maximum compression numbers from cherry-picked benchmarks. At low quality settings or for graphics-heavy screenshots, AVIF or even plain WebP can match or beat JPEG XL. Run tests on your actual assets before committing.

What Would Have to Happen for 2027 to Be the Year

Watch four signals through late 2026 and into 2027. One: any Chromium commit or Intent-to-Ship thread re-introducing JXL — even behind a flag, it would signal a policy shift. Two: a marquee adopter shipping JPEG XL at scale, the way Netflix championed AVIF. Three: continued expansion of default support in non-browser software — office suites, CMS pipelines, cloud image CDNs offering automatic JXL variants. Four: hardware encoder IP appearing in phone SoCs, which historically forces browser engines to follow because camera pipelines demand it.

My realistic read: a full Chrome reversal by 2027 is possible but not probable — call it a 25 to 35 percent chance based on current public posture. More likely is continued drift toward de facto support through tooling and CDN transcoding, with true universal browser coverage arriving sometime between 2027 and 2029 if at all. Plan accordingly: adopt for archives and progressive enhancement now, keep AVIF/WebP fallbacks mandatory, and revisit the decision the moment Chromium moves.

Cost and Effort Considerations

The format itself costs nothing — libjxl is BSD-licensed open source, and the ISO standard's core profile is royalty-free. Your real costs are engineering time and storage duplication during transition. Encoding a 100,000-image library with cjxl might take a few hours of compute versus days for AVIF, which is precisely why large platforms find JXL attractive operationally. CDN providers increasingly charge nothing extra for serving additional format variants since it is just cache storage. Budget realistically for maintaining three variants per image (JXL, AVIF, WebP) during the transition window — roughly 1.3x storage overhead — and drop variants as browser coverage consolidates.

Bottom Line

JPEG XL in 2026 is technically excellent, partially adopted, and politically stuck. Safari and Firefox users get the benefits today; everyone else needs fallbacks. Treat 2027 as a watch-and-hedge year rather than a deadline: build the dual-encoding pipeline, archive in JXL where the lossless JPEG recompression saves you real money, and let Chromium's behavior — not wishful thinking — dictate when you make it your primary web delivery format.