JPEG XL vs AVIF compression: which image format actually wins in 2026?

The Direct Answer: JPEG XL vs AVIF Compression

If you want the shortest possible verdict on jpeg xl vs avif compression: JPEG XL wins on raw compression efficiency, lossless performance, and backward compatibility with legacy JPEG files, while AVIF wins on ecosystem support, browser adoption, and tooling maturity as of August 2026. For most websites shipping images to real users today, AVIF remains the pragmatic default; for archives, photography workflows, and anyone who cares about transcoding old JPEG libraries without quality loss, JPEG XL is technically superior.

Also worth reading: What are the best digital payment guides for everyday apps in 2026, and how do I actually choose the right payment app? · Payment orchestration vs payment gateway: what's the difference and which one does your business actually need? · Account-to-account payments vs cards: which should merchants and consumers actually use in 2026?

The gap has narrowed on the browser side. After Google removed JPEG XL from Chrome in early 2023 citing insufficient industry interest, coverage through 2025 and into 2026 reported that Chrome was rekindling support for the format, which changes the calculus considerably. Safari has supported JPEG XL since version 17 (September 2023), and Firefox shipped it behind a flag before enabling it by default in Firefox 133 in late 2024. That means all three major browser engines either support or are moving toward supporting JXL, while AVIF has been enabled everywhere since roughly 2020–2022.

Neither format costs anything to license. Both are royalty-free, which distinguishes them from HEIC/HEIF, where patent pools still complicate adoption outside Apple's ecosystem. The decision therefore comes down to engineering effort, compression numbers, and how much you trust each format's long-term trajectory — not money.

Why This Comparison Exists at All

Both formats were designed to solve the same problem: JPEG is thirty-plus years old, blocky at low bitrates, and wasteful by modern standards, yet billions of JPEG images exist and cannot simply be discarded. The Joint Photographic Experts Group developed JPEG XL (standardized as ISO/IEC 18181, finalized around 2021–2022) as a genuine successor that can losslessly re-compress existing JPEGs. AVIF grew out of Netflix's work with the Alliance for Open Media, adapting the AV1 video codec's intra-frame coding for still images, with first stable browser support arriving in Chrome 85 in 2020.

The two formats take philosophically different approaches. AVIF borrows proven video compression machinery — it inherits AV1's entropy coding and prediction tools, which is why it compresses well but encodes slowly. JPEG XL was built from scratch for still imagery, using a modular mode plus a VarDCT (variable-block-size DCT) mode, and includes a unique feature neither AVIF nor WebP offers: a lossless 'JPEG recompression' mode that shrinks existing .jpg files by roughly 20% while allowing perfect reconstruction of the original bytes.

That single feature explains much of the enthusiasm among archivists and photographers. A library of five million legacy JPEGs can be cut to about 80% of its size with zero generational loss, then expanded back to byte-identical originals whenever needed. AVIF cannot do this; converting a JPEG to AVIF is a one-way, lossy trip.

Compression Efficiency: What the Numbers Show

Independent comparisons have consistently placed both formats well ahead of JPEG and WebP, with JPEG XL generally holding a slight edge over AVIF, particularly at high visual quality. Typical findings across published studies and community benchmarks:

• Against baseline JPEG at equivalent perceptual quality (measured with metrics like SSIM, Butteraugli/DSSIM, or VMAF-derived scores), AVIF typically saves 30–50% of file size, and JPEG XL saves roughly 35–55%.
• At very low bitrates, AVIF's aggressive prediction sometimes produces smaller files, but with characteristic AV1-style artifacts — smearing around fine textures and text.
• At high quality (the range photographers care about), JPEG XL tends to win, often producing visually transparent results at smaller sizes than AVIF.
• For lossless compression, JPEG XL is decisively ahead: it usually beats PNG by 30–40% and beats AVIF's lossless mode by a meaningful margin, because AVIF's lossless path was never a design priority.

Encoding speed is another differentiator worth stating plainly. JPEG XL's libjxl encoder is fast — often comparable to or faster than mozjpeg at default settings, and dramatically faster when using its 'falcon' speed tiers. AVIF encoding via libaom is notoriously slow; even the faster SVT-AV1 and rav1e paths are typically several times slower than libjxl for equivalent quality. For a site generating images on the fly or re-encoding large catalogs, this matters as much as the final file size.

Google's own response to JPEG XL's momentum was Jpegli, announced in April 2024 — an improved JPEG encoder/library promising roughly 35% better compression than classic libjpeg-turbo at similar speeds, designed to keep the old format competitive rather than adopt a new container. It is a sign that the incumbent isn't standing still.

Side-by-Side Comparison Table

One caveat about any table like this: benchmark results vary with content type. Photographic material favors JPEG XL more consistently than screenshots, illustrations, or AI-generated images, where AVIF occasionally matches or beats it. Always test on your own corpus before committing.

Browser and Ecosystem Support in August 2026

Support is the axis where the story genuinely shifted between 2023 and 2026. In January 2023, Chrome 110 shipped without JPEG XL, and Google formally declined to pursue it, arguing that existing formats covered user needs. The Register, Coywolf, HotHardware, and others documented the backlash and the subsequent years of advocacy. By late 2024, Firefox had enabled JPEG XL by default in release builds, Safari had supported it since September 2023, and reporting through 2025–2026 indicated Chrome was bringing JXL back — though enterprises should verify the exact version and whether it ships behind a flag in their managed channels before relying on it.

AVIF, meanwhile, enjoys near-universal support: Chrome and Edge since 2020–2022, Firefox since version 93 (October 2021), Safari since 16.4 (March 2023). Beyond browsers, AVIF is embedded deeper in operating systems — Android supports it natively, Windows 11 handles it with free codec extensions, and iOS renders it in web contexts. JPEG XL's OS-level integration remains spottier: macOS Preview and iOS handle JXL, but Windows users may need extensions, and many third-party apps still ignore it.

For a payment-adjacent site like L0t's typical audience — merchant dashboards, checkout flows, fintech marketing pages — the practical rule is simple: serve AVIF today with JPEG fallbacks via the HTML <picture> element or content negotiation, and add JPEG XL as a third source once Chrome's support is confirmed stable in your analytics data. Progressive enhancement costs little and protects you from edge-case breakage in older embedded webviews, which are common in mobile banking and wallet apps.

Practical Steps to Adopt Either Format

Start by auditing what you actually serve. Run your top pages through Lighthouse or WebPageTest and check what percentage of page weight is images; for most content-heavy sites it is 50–70%. Then pick your conversion pipeline based on volume. For small sites, Squoosh (browser-based) handles both formats interactively. For automation, use sharp (Node.js), pillow-jxl-plugin plus pillow-avif-plugin (Python), ImageMagick 7.1+, or ffmpeg for AVIF. Cloudinary, imgix, and Cloudflare Images all support AVIF today, with varying JPEG XL availability — check your vendor before assuming.

Set sensible quality targets rather than chasing maximum compression. For AVIF, an aq-mode-aware quality setting around 45–60 in libaom terms usually lands in the visually transparent zone for photos; for JPEG XL, distance values between 1 and 2 (libjxl's d parameter) are the sweet spot for photographic content. Never convert blindly at defaults and ship — spot-check faces, text overlays, gradients, and fine repeating patterns, because those are where each codec fails differently.

Implement fallbacks correctly. The robust pattern is a <picture> element listing JXL, then AVIF, then WebP, then JPEG as the src, letting the browser pick the first it understands. Alternatively, use Accept-header-based content negotiation at the CDN layer so URLs stay clean. Cache aggressively — these conversions are expensive enough (especially AVIF) that you should encode once and reuse, not encode per request. Finally, measure: track p75 Largest Contentful Paint before and after. If you don't see improvement, your images weren't the bottleneck and the migration bought you nothing.

Common Mistakes People Make

The most frequent error is treating format choice as a one-time decision rather than a pipeline property. Teams convert their existing library to AVIF, then keep uploading JPEGs from editors who haven't changed their workflow, ending up with a mixed bag nobody maintains. Bake conversion into your upload process instead — every new asset should automatically produce the full source set.

Second, people over-index on headline compression percentages from benchmarks run on Kodak-style photo sets. Real-world gains depend heavily on your actual images. A site full of flat-color UI screenshots may see modest AVIF/JXL gains over well-tuned WebP; a photography portfolio will see dramatic ones. Benchmark on your own top 100 images before writing blog posts claiming savings.

Third, ignoring decode cost. AVIF decodes slower than JPEG too — not just encodes — and on low-end Android devices in emerging markets (exactly the audience many fintech products target), heavy AVIF hero images can delay rendering despite smaller downloads. JPEG XL decodes quickly, which partially offsets its thinner ecosystem. Fourth, forgetting EXIF and color profiles: both formats can carry ICC profiles and metadata, but naive conversion pipelines frequently strip them, causing washed-out colors on wide-gamut displays. Verify Display P3 handling if your photography depends on it.

Finally, some teams assume JPEG XL is 'dead' because of the 2023 Chrome removal, or conversely assume it has 'won' because of the 2025–2026 comeback reports. Neither is true. Its fate depends on Chrome shipping and on CMS and design-tool adoption, both of which remain incomplete. Hedging with multi-format delivery is the only strategy that survives either outcome.

When to Choose Which — Decision Criteria

Choose AVIF now if you operate a consumer-facing website with heterogeneous traffic, need guaranteed rendering across all current browsers and Android webviews, use a managed image CDN, or prioritize animated images alongside stills. Its tooling is boring and reliable, which in production infrastructure is a virtue. The compression penalty versus JPEG XL — typically 5–10% larger files at equal quality — is a rounding error compared to the risk of broken images for a slice of users.

Choose JPEG XL if you manage photographic archives, digital asset management systems, or backup libraries where the lossless JPEG transcoding feature alone justifies adoption; if you serve high-quality imagery where per-file savings compound across millions of assets; or if you control your client environment (kiosks, internal tools, Electron apps) and can bundle decoder support yourself. Also choose it if storage bandwidth costs dominate and you can tolerate serving AVIF fallbacks to unsupported clients in the interim.

Run both if you're ambitious: modern CDNs make multi-format negotiation cheap, and the marginal storage cost of keeping three renditions is trivial next to the engineering cost of a second migration. The worst option is waiting for a single winner to be declared — the industry spent a decade failing to do exactly that with WebP, HEIC, and JPEG 2000 before it.

Costs, Risks, and Long-Term Outlook

Direct monetary cost is zero for both formats — no licensing fees, no patent royalties, unlike HEIC where licensing friction persists outside Apple platforms. Indirect costs exist: engineer time for pipeline changes (typically days, not weeks, for a standard web stack), increased origin storage for multiple renditions, and CPU load for batch encoding, which is non-trivial for AVIF at scale — budget for it or pre-generate during off-peak hours.

The main risk on the AVIF side is stagnation: it is tied to AV1's generation of codecs, and while excellent, it will eventually look dated next to whatever follows. The main risk on the JPEG XL side is repetition of history — if Chrome's return stalls again or ships only behind flags, JXL could spend another half-decade as a niche format beloved by enthusiasts and ignored by CMS vendors. Watch two signals through late 2026: whether Chrome enables JXL by default in stable releases, and whether WordPress, Shopify, and the major CDNs add first-class JXL output. Those two events, more than any benchmark, will decide the format war.

For everyday consumers, the practical takeaway is modest: phone cameras shooting HEIC or JPEG aren't going anywhere soon, and switching your camera's default format (as Fstoppers and SammyGuru have explored) yields smaller storage footprints but compatibility headaches with older computers and printing services. The format battle mostly matters to developers, publishers, and anyone paying bandwidth bills at scale — which, given how much of the modern web is images inside payment pages, product listings, and marketing funnels, includes more businesses than realize it.