JPEG XL vs AVIF vs WebP, 2026 edition

Three modern image formats arrived in the last decade. Each one promises smaller files at the same quality. In 2026 the picture is finally clear: each format has a job it does better than the others.

TL;DR

• AVIF wins web delivery. Roughly 30 to 50 percent smaller than JPEG, all modern browsers ship it.
• WebP wins compatibility. Slightly larger than AVIF, but supported in browsers a decade older.
• JPEG XL wins archives. Lossless re-encoding of an existing JPEG saves about 20 percent storage with zero quality loss and is fully reversible.

The rest of this post explains why each of those claims holds, what the benchmarks hide, and how to actually pick between them.

What benchmarks don’t show

Most format comparisons publish a graph of file size against PSNR or SSIM on a fixed test set, and call it a day. The graphs are not wrong, but they collapse three different questions into one.

The first question is encoding cost. AVIF at high quality is slow. JPEG XL is fast. WebP sits in between. If you are batch-converting a thousand photos, encoder speed dominates wall time and the file size delta becomes a rounding error against your patience.

The second question is decoding behavior. AVIF decoders allocate a lot of memory on large images because they were built on a video codec. JPEG XL decoders are designed for progressive rendering. WebP decoders are the most boring and the most predictable. On a phone scrolling through a feed, decoding cost matters more than file size.

The third question is what happens at the edges. AVIF struggles with very thin lines, sharp text on flat backgrounds, and certain gradient patterns. JPEG XL handles all of those cleanly. WebP at low quality starts to look like JPEG at low quality, which is to say, blocky. The benchmarks rarely include text-heavy screenshots or line art, so this difference disappears from the charts.

You cannot pick a format from a graph. You pick it from the job.

AVIF in 2026

AVIF is the format you reach for when an image is going on a public web page and you care about page weight.

Browser support landed across Chrome, Firefox, Safari, and Edge between 2020 and 2023. By 2026 you can treat AVIF as a baseline format for delivery, with a JPEG or WebP fallback for very old browsers if your analytics show traffic from them.

The compression story is real. A photograph that takes 800 KB as a quality-80 JPEG will land somewhere between 400 and 550 KB as AVIF at visually equivalent quality. On photos with smooth gradients and natural textures the savings can be larger. On photos with very fine detail the encoder works harder and the file sometimes only matches WebP.

AVIF’s main downside is encoding time. A single high-resolution photo can take seconds to encode at the slowest, highest-compression settings. For a batch of a thousand, you want a faster encoder preset, a multithreaded pipeline, or both.

WebP in 2026

WebP is the format you reach for when you need broad compatibility today and you do not want to think about fallbacks.

It has been in Chrome since 2010 and in Safari since 2020. By 2026 every browser that anyone is realistically using supports it. It also has the most boring decoder, which is a compliment. Memory use is predictable, decode speed is fast, and there are no surprises on edge cases.

The file size story is the weakest of the three. WebP beats JPEG by maybe 25 to 35 percent on typical photos, which sounded great in 2014 and sounds modest now that AVIF exists. But the format also supports lossless encoding, which is where it actually shines. Lossless WebP often beats lossless PNG by 20 to 30 percent on images with transparency, and that is still the most widely supported way to ship a small transparent image to the web.

If you are reading this on a brand-new browser and care about every kilobyte, AVIF wins. If you ship to a long tail of devices and operating systems and want one format that just works, WebP is still the safe pick.

JPEG XL in 2026

JPEG XL is the format you reach for when you are storing photos rather than serving them.

Browser support is the awkward part. Safari 17 and iOS 17 ship a JXL decoder. Chrome and Firefox have not enabled it by default as of 2026, though both have shipped the decoding code at various points and removed it again. For web delivery this is a blocker.

For archives it is not. The format spec is final. Decoders exist as small libraries. The trick JXL pulls that no other format can do is lossless recompression of an existing JPEG: read the JPEG’s coefficients, repack them with better entropy coding, and write a JXL file that decodes back to the byte-identical original JPEG. The savings are around 20 percent on typical camera files and the operation is fully reversible.

That property changes the question. With AVIF or WebP, “should I convert my photo library” is a one-way commitment. With JXL lossless transcoding it is reversible. If you change your mind, the JPEGs are still in there.

JXL also handles a wider gamut, higher bit depth, and animated images more cleanly than its peers. Those features matter less for the average user and more for photographers, designers, and anyone working with HDR or wide-color content.

A quick decision tree

• Web page, modern browsers, photographs? AVIF.
• Web page, broad compatibility, no fallback budget? WebP.
• Transparent image for the web? Lossless WebP.
• Photo archive, you already have the JPEGs? JXL lossless transcode.
• New image from scratch, archival quality? Lossless JXL.
• One file that has to open anywhere? JPEG via jpegli, quality 85.

How Sqz reaches for each

Sqz ships all three encoders plus jpegli, PNG, and HEIC. For a typical workflow the app picks defaults that match the decision tree above, but exposes every quality and effort setting if you want to tune them. The lossless JPEG-to-JXL path is the one feature no other Mac App Store image compressor offers in 2026, and it is the reason archival users tend to install Sqz first and then discover the AVIF and WebP encoders later.

You do not need a tool to use any of these formats. You need a workflow. The format is the last decision, not the first one.