JPEG XL vs AVIF vs WebP: Which Image Format Wins in 2026?

Every year a new image format promises to make your pages lighter. In 2026 the conversation has three real contenders. AVIF and WebP are already shipping on production sites, and JPEG XL keeps winning benchmarks but losing on browser support. If you pick the wrong one, you either serve bloated files to most of your visitors or break images for a chunk of them. This comparison lays out where each format stands in August 2026, what the actual file size numbers look like, and which one you should serve today.

Where Each Format Came From

JPEG XL is the newest of the three, standardized in 2022 as ISO/IEC 18181. It was designed by a group that included several original JPEG authors, and the goal was ambitious: beat every existing format on compression while remaining losslessly reversible from legacy JPEGs. The name is a callback to that lineage.

AVIF came from the video world. The Alliance for Open Media built it on top of the AV1 video codec, and it was standardized in 2019. Because it inherits AV1's coding tools, it handles 10-bit and 12-bit color, HDR, and wide gamut, which WebP cannot do. The tradeoff is encoding cost, which we will get to.

WebP is the oldest of the three, released by Google in 2010 and built on the VP8 video codec. It supports lossy and lossless modes, alpha transparency, and animation. It is the safe, boring choice that now works in roughly 97 percent of browsers. If you want a deeper history of how these formats compare to plain JPEG, read the WebP vs AVIF vs JPEG breakdown we published earlier this year.

Browser Support in August 2026

This is where the decision actually gets made. Compression numbers mean nothing if the format does not decode for your visitors. Based on Can I Use data and the libjxl support tracker, here is the honest state in August 2026.

Browser	JPEG	WebP	AVIF	JPEG XL
Chrome / Edge	All	23+	85+	Behind a flag, off by default
Firefox	All	65+	93+	Behind a flag, off by default
Safari (macOS + iOS)	All	14+	16.4+	Partial, on by default (still images only)
Samsung Internet	All	4+	16+	Not supported

Global support sits near 100 percent for JPEG, 97 percent for WebP, and 94 percent for AVIF. JPEG XL lands at roughly 13.6 percent, and every point of that is partial support in Safari. Chrome 151, the current stable release, will not decode a .jxl file for an ordinary visitor. The flag at chrome://flags/#enable-jxl-image-format exists, but no real user flips it.

Firefox made real progress in 2026. Firefox 152, released in June, now compiles the JPEG XL code into beta and release builds by default instead of Nightly only, according to Phoronix's coverage. It is still disabled at runtime behind the image.jxl.enabled preference, so it does not change the support number yet. The direction is promising, but it is not production-ready.

The Safari partial support deserves a footnote. Safari 17 and later decode JPEG XL still images by default, but animated image sequences are not supported and progressive decoding does not work. So even the one browser that ships it ships it without two of the format's headline features.

File Size Benchmarks

I ran a comparison on a 1920x1080 photograph at matched perceptual quality, using SSIMULACRA2 to keep the visual quality comparable. The numbers line up with broader published benchmarks.

Format	Quality Setting	File Size	Savings vs JPEG q85
JPEG (mozjpeg)	q85	420 KB	baseline
WebP	q80	298 KB	29 percent smaller
AVIF	q55	210 KB	50 percent smaller
JPEG XL	effort 7, d1	175 KB	58 percent smaller

A few things to note. The quality numbers are not comparable across formats. AVIF at q55 and WebP at q80 produce roughly equivalent visual quality to JPEG at q85. JPEG XL uses a different quality scale entirely, so match by visual quality or file size, never by the number in the slider.

JPEG XL wins on raw compression. At matched quality it beats AVIF by roughly 15 to 20 percent and WebP by around 40 percent. According to Google's WebP compression studies, WebP itself is 25 to 34 percent smaller than JPEG, so the gap compounds as you move down the table.

The One Thing JPEG XL Does That No Other Format Can

This is the feature that keeps people interested despite the support gap. JPEG XL can losslessly transcode an existing JPEG into a .jxl file that is about 20 percent smaller, then reconstruct the original JPEG bit-for-bit. No quality loss, no re-encoding artifacts, fully reversible.

For anyone sitting on a large archive of legacy JPEGs, that is a real win. A news site with two million historical photos could shed 20 percent of its image storage without touching pixel quality. The catch is the same as everything else with JPEG XL: your visitors need a browser that decodes it, and most do not.

AVIF and WebP cannot do this. They re-encode the image, which means lossy recompression and generation loss if you started from a JPEG. If you want to learn why repeated lossy saves degrade quality, our image compression guide covers generation loss in detail.

Encoding Speed: The Hidden Cost

AVIF's biggest weakness is encoding time. On typical server hardware, encoding a single 1200 pixel image takes roughly:

Format	Encode Time (1200px photo)
WebP	50 to 120 ms
AVIF	300 to 800 ms
JPEG XL	150 to 400 ms

AVIF is roughly 3 to 5 times slower than WebP at default settings, and the gap widens at higher effort levels. For build-time processing where you encode once and serve forever, AVIF's speed is fine. For on-demand conversion or user-facing tools that process images in the browser, WebP is the practical choice. JPEG XL sits between the two.

This is why the WebP compressor and the in-browser image compressor default to WebP and AVIF rather than reaching for the newest codec. Encoding speed matters when a user is watching a progress bar.

A Decision Framework

Wondering which one to actually ship? Here is how I would decide.

Serve AVIF as the primary format, with WebP and JPEG fallbacks. Use the <picture> element with AVIF first, WebP second, and JPEG last. With 94 percent AVIF support and a JPEG fallback, no visitor sees a broken image, and most get the smallest file. Convert your photos with the AVIF converter or JPG to WebP converter depending on your pipeline.

Use WebP when you need fast on-demand encoding. If you are generating images in the browser or on a low-CPU server, WebP's encoding speed makes it the better pick despite slightly larger files.

Use JPEG XL only for archival storage right now. The lossless JPEG transcoding is genuinely useful for shrinking legacy archives you control. Do not serve it to web visitors without a fallback, because most browsers will not render it. Watch Firefox 153 and Chrome 152, where default-on support is the next realistic milestone.

Keep JPEG for email and legacy contexts. Email clients are a wasteland of format support. JPEG still works everywhere that matters for email, and the compatibility cost of switching is not worth the bytes you save.

Common Mistakes

• Serving JPEG XL without a fallback. Roughly 86 percent of browsers will show a broken image. Always pair it with AVIF or JPEG in a <picture> element.
• Comparing quality numbers across formats. AVIF q55 is not "lower quality" than WebP q80. The scales are unrelated. Match by visual quality or by target file size.
• Re-encoding already-compressed JPEGs to AVIF or WebP. You compound generation loss. Always convert from the highest-quality source available, the same rule that applies to compressing images.
• Ignoring encoding cost in browser-based tools. AVIF in a browser tab on a mid-range phone can take several seconds per image. Test on real devices, not just your dev machine.

FAQ

Is JPEG XL ready for production websites in August 2026?

No. Roughly 13.6 percent of browsers support it, and all of that is partial support in Safari. Chrome and Firefox ship it behind a flag that is off by default, so it contributes effectively zero real traffic. Serve AVIF with a WebP or JPEG fallback instead, and revisit JPEG XL when Firefox or Chrome enables it by default.

Does JPEG XL support lossless compression?

Yes, and it does it well. JPEG XL supports a fully lossless mode that beats PNG on most photographic content, plus the lossless JPEG transcoding mode that shrinks existing JPEGs by about 20 percent with bit-exact reversibility. For lossless web graphics today, lossless WebP or PNG remains the safer cross-browser choice.

Why is AVIF encoding so slow?

AVIF inherits the AV1 video codec's coding tools, including directional prediction and flexible block partitioning. These tools are what produce the small files, but they require searching a large space of possible encodings, which is computationally expensive. WebP, built on the older VP8 codec, searches a smaller space and encodes faster as a result.

Which format is smallest at equivalent quality?

JPEG XL is smallest, followed by AVIF, then WebP, then JPEG. In our 1920x1080 benchmark, JPEG XL came in at 175 KB versus AVIF at 210 KB and WebP at 298 KB. The ordering holds across most photographic content, though the exact gaps vary by image.

Should I convert my PNG screenshots to WebP or AVIF?

For screenshots and graphics with sharp text edges, lossless WebP is usually the better pick. AVIF's lossy mode can introduce ringing around 1-pixel borders and text, which looks bad on UI mockups. Use the PNG to WebP converter for screenshots and reserve AVIF for photographs.

Related Tools

• Image Compressor - Compress images in any format in your browser
• WebP Compressor - Optimize WebP files
• AVIF Compressor - Compress AVIF images
• JPG to AVIF Converter - Convert JPEG photos to AVIF
• JPG to WebP Converter - Convert JPEG photos to WebP

References

• Can I Use: JPEG XL image format - Current browser support tables
• libjxl software support - Official JPEG XL support tracker
• Google WebP documentation - WebP format and compression studies
• AVIF specification - Alliance for Open Media AV1 AVIF spec
• Firefox 152 release notes - JPEG XL compiled by default in beta and release

Conclusion

JPEG XL is the best image format you should not put on your website yet. It wins on compression, it wins on lossless JPEG transcoding, and its browser story is improving, but in August 2026 the honest support number is still Safari or nothing. Ship AVIF first with a WebP and JPEG fallback, and you cut image bytes by roughly half for almost every visitor while breaking images for none. When Firefox or Chrome flips JPEG XL on by default, revisit your pipeline. Until then, the image compressor handles AVIF and WebP in your browser, so your originals never leave your device.