WebP vs AVIF vs JPEG XL: Modern Image Formats Compared

Why This Comparison Matters in 2026

JPEG turned 33 years old in 2025. It is the most universally supported image format in computing history and it is also showing its age. JPEG cannot do alpha transparency. It cannot do animation. It is locked to 8 bits per channel, which makes it the wrong choice for any HDR display. Its compression is mediocre by modern standards. For most of the last decade, the question of "what comes after JPEG" has had no clean answer.

That changed gradually between 2018 and 2024. WebP became universally supported when Apple finally added it to Safari 14 in late 2020. AVIF reached production-ready in 2022 with Chrome, Firefox, and Safari support. JPEG XL was standardized as ISO/IEC 18181 in 2022, removed from Chrome the same year, and then partially revived in 2024 when Apple shipped it in Safari 17. Today all three formats decode in at least one major browser engine, but only one decodes everywhere. That single fact drives most of the practical decisions.

The other reason this matters now is that displays have outpaced JPEG. Phones from 2023 onward routinely capture in HDR. Laptop screens in 2026 commonly do 10-bit color and P3 wide gamut. JPEG cannot represent any of that without dithering or banding. If your audience uses anything more modern than a 2018 monitor, sending them JPEG is silently throwing away part of the photo.

WebP: The Pragmatic Default

WebP was announced by Google in September 2010, based on the VP8 video codec. The lossy compression mode uses VP8 keyframe encoding; the lossless mode is a custom design. Both produce smaller files than JPEG and PNG respectively at comparable visual quality. The encoder, libwebp, has been stable and widely deployed for over a decade.

The numbers Google originally published in 2010 claimed WebP beat JPEG by 25 to 34 percent at equivalent quality. Independent benchmarks since then have generally agreed, though the gap narrows for already-small images and widens for photographs with smooth gradients. The lossless mode usually beats PNG by 20 to 30 percent.

What WebP gives up:

• Bit depth. WebP is locked to 8 bits per channel. Same limit as JPEG. So if you need HDR or wide-gamut displays to look right, WebP does not help.
• Animation. Animated WebP exists but its support is patchy in image editors. The encoder is also slower than the still-image path.
• Progressive decoding. WebP does not stream like progressive JPEG. The user sees nothing until the file is fully downloaded, then the whole image appears.
• Color profile handling. WebP's ICC profile support exists but is inconsistent across encoders. If you need accurate color management, test before committing.

On the plus side, encode and decode are fast, the format is supported in every browser shipping in 2026, and most server-side image pipelines (Sharp, ImageMagick, Pillow, libvips) handle it without extra dependencies. If you want one format that works everywhere and saves bandwidth, WebP is the safe answer.

AVIF: Big Compression Wins, Slow to Encode

AVIF (AV1 Image File Format) was published in 2019 by the Alliance for Open Media. It is essentially a single keyframe of an AV1 video wrapped in the HEIF container (ISO/IEC 23000-22, the same wrapper Apple uses for HEIC). Decoding is fast. Encoding is the well-known catch.

AVIF compresses photos roughly 50 percent smaller than JPEG at equivalent visual quality, and roughly 20 percent smaller than WebP. For low-fidelity targets like blog hero images, the savings can be even bigger. For pixel-perfect technical images with hard edges, the gap narrows.

Compared to WebP, AVIF brings real upgrades:

• 10 and 12 bit depth. Can represent HDR content. PQ and HLG transfer functions are supported.
• Wide gamut color. Native support for Rec. 2020 and DCI-P3 color spaces.
• Better quality at low bitrates. The block-based AV1 prediction handles smooth gradients and skin tones better than VP8 or DCT-based JPEG.
• Animation. AVIF can carry animated sequences. Compression for animations is excellent.

The downside is encoder speed. The reference encoder libaom is correct but glacial; encoding a single 4K photo at high quality settings can take 30 to 90 seconds on a modern CPU. Faster encoders exist (rav1e, SVT-AV1, the standalone cavif) but they sacrifice compression efficiency for speed. If you have a build pipeline that processes tens of thousands of images, you have to make a real decision about how much CPU time you can spend per file.

JPEG XL: The Format the Web Almost Got

JPEG XL is the format with the most interesting story and the most uncertain future. It was developed by Cloudinary and Google Research and standardized as ISO/IEC 18181 in 2022. It promises better compression than AVIF, lossless transcoding from existing JPEG files (a JPEG XL recompression is about 20 percent smaller than the original JPEG and reversible), 8 to 32 bit support, alpha transparency, animation, progressive decoding by quality, and HDR. On paper it is the closest thing to a universal successor to JPEG that has ever existed.

The political story is messier. In October 2022, Chrome removed JPEG XL support from behind its experimental flag (Issue 178058) on the stated rationale that there was insufficient ecosystem interest. Mozilla followed by keeping it disabled by default in Firefox. For a year, JPEG XL looked stillborn.

Then in June 2023, Apple announced JPEG XL support in Safari 17 at WWDC. macOS Sonoma and iOS 17 added native decoding to the OS frameworks. By mid-2024, Adobe had added JPEG XL output support to Camera Raw and Lightroom. Firefox enabled JPEG XL behind image.jxl.enabled in 2024 and the consensus on actually flipping the default has been creeping toward "yes." Chrome remains the holdout. As of April 2026, you cannot serve JPEG XL to a Chromium browser and have it render.

What JPEG XL gives you in environments where it is supported:

• The best compression of the three. Roughly 60 percent smaller than JPEG at equivalent visual quality, around 15 to 20 percent smaller than AVIF.
• Lossless transcoding from JPEG. Take an existing JPEG library, run cjxl over it, and you get smaller files that can be perfectly reverted to the original JPEG byte-for-byte. This is unique among modern formats.
• True progressive decoding. The bitstream is layered by quality. Browsers can render a coarse version of the image after a few hundred bytes, refining as more data arrives. This is the property that progressive JPEG had, that WebP and AVIF lack.
• Up to 32 bits per channel. Can represent any HDR or scientific imaging workflow.
• Fast encode and decode. The reference encoder libjxl with default settings is roughly 5 to 10 times faster than libaom-AVIF at equivalent visual quality. Decode is also faster than AVIF on most hardware.

The catch remains delivery. Until Chromium ships, JPEG XL is essentially an Apple-ecosystem and tooling format, not a public-web format. If your audience is mostly iOS and macOS, you can use it. If your audience includes the 65 percent of desktop browsers running Chromium-based engines, you cannot.

Compression Efficiency: Real Numbers

Numbers vary by source image. The values below are representative of what most independent benchmark suites (Cloudinary's, Daniel Aleksandersen's, the libjxl team's published results) show for natural photographs at "visually lossless" quality settings, normalized so JPEG at quality 80 is the baseline.

The numbers tell two stories. First, all three modern formats beat JPEG by a wide margin, and JPEG XL produces the smallest files of all. Second, encoder speed is the gap that matters at scale. AVIF's 50 percent savings come at the cost of 20 to 50 times more CPU per image during encode. JPEG XL gets nearly the same compression at a small fraction of the CPU cost. WebP is the cheapest CPU-wise but gives up 20 percent of the savings the others offer.

One footnote that surprises people: Google's own jpegli encoder, released in 2024, brings standard baseline JPEG within striking distance of WebP for many photographs. If browser compatibility is the only thing keeping you on JPEG, switching from libjpeg-turbo to jpegli can win back 15 to 25 percent of file size with zero format changes on the client side.

Browser Support Matrix

The cleanest way to think about delivery is by what you can ship today, in April 2026, with the expectation that it will render correctly. These versions are when each browser engine added support, and they hold for desktop and mobile equivalents unless noted.

The pragmatic reading: WebP is universal. AVIF is universal. JPEG XL is supported only on Apple platforms and behind a Firefox flag. Until and unless Chromium ships JPEG XL, the format is excellent for internal pipelines and Apple-targeted apps but cannot be served as the only resource on a public website.

The standard pattern for production today uses the HTML <picture> element with multiple sources and lets the browser pick:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero photograph" width="1280" height="720">
</picture>

The browser walks the source list top to bottom, picks the first format it understands, and loads only that file. Safari 17 picks JPEG XL. Chrome picks AVIF. Older browsers fall through to JPEG. Each user gets the best image their browser can decode.

Picking the Right Format Today

After all the trade-offs, the actual decision tree is shorter than you might expect. Here is what I use:

If you are starting fresh and you want a single rule that you do not have to revisit, "use WebP" is the answer that will be correct for 90 percent of cases through at least 2027. If you have a build pipeline and care about getting the last 20 percent of bytes out of every image, layer AVIF on top with a picture-element fallback. If you are an Apple-only ecosystem, JPEG XL is genuinely worth using today. If your tooling needs are heavier and you want help thinking through them, the image optimization guide covers the broader pipeline beyond just format choice.

Converting Between Formats with StackConvert

When you need to convert one image at a time without spinning up a build pipeline, the StackConvert online image converter handles JPEG, PNG, WebP, and GIF conversion in your browser. Files never leave your device, which matters when you are testing whether a marketing photo or a product mockup converts cleanly before committing to a format change.

For batch conversion of a whole directory, command-line tools are still the right answer. The minimum-viable one-liners I keep around:

# JPEG to WebP (quality 85, comparable to JPEG q90)
cwebp -q 85 input.jpg -o output.webp

# JPEG to AVIF with reasonable defaults
avifenc --speed 6 -q 75 input.jpg output.avif

# JPEG to JPEG XL (lossless transcode of an existing JPEG)
cjxl --lossless_jpeg=1 input.jpg output.jxl

# JPEG XL back to JPEG (perfect round-trip if cjxl --lossless_jpeg was used)
djxl output.jxl recovered.jpg

For a more complete picture of how format choice fits into a real image-delivery workflow (responsive sizes, lazy loading, srcset patterns, CDN integration), the online image converter walkthrough is a good companion read.

Frequently Asked Questions

Should I switch from JPEG to WebP today?

Yes, with very few exceptions. WebP has had universal browser support since Safari 14 in 2020, encoders are everywhere, and the typical size reduction is 25 to 35 percent. The only reasons to stay on JPEG are if you cannot run a server-side image pipeline or if you are delivering to a known audience of pre-2020 browsers (some embedded kiosks, some industrial control systems, some corporate IE-replacement browsers).

Why is AVIF so slow to encode?

AVIF is a single keyframe of an AV1 video, and AV1 was designed for streaming video where each frame can take milliseconds to encode but they spread the cost across many frames. The reference encoder libaom prioritizes compression efficiency over encode speed. SVT-AV1 (developed by Intel and Netflix) and rav1e (Mozilla, Rust) trade some compression for much faster encode and are the right choice for build pipelines.

Can I serve JPEG XL on a public site in 2026?

Only if you accept that Chromium browsers will fall back to your other source. Use a <picture> element with JPEG XL first, then AVIF, then WebP, then a JPEG fallback. Safari 17+ users get JPEG XL. Everyone else gets the next best supported option. There is no harm in including JPEG XL even if most users will not see it; the browser just skips the unsupported source.

Is JPEG XL going to be added to Chrome eventually?

Probably, but I would not bet a roadmap on it. The Chromium team's stated objection in 2022 was insufficient ecosystem interest, and the situation has shifted significantly since then with Apple's adoption and Firefox's progress. Several Chromium-derived browsers (Edge through Microsoft, Opera, Brave) have signaled willingness to ship it independently if the core team continues to refuse. As of April 2026, no announcement has been made.

What does "lossless transcoding from JPEG" actually mean?

It means that JPEG XL has a special mode where it takes an existing JPEG file, repacks the same DCT coefficients with better entropy coding, and produces a smaller file. The new file decodes to a byte-perfect reproduction of the original JPEG. You can convert old archives without quality loss and revert at any time. No other modern format does this; AVIF and WebP both require full re-encoding from a reference image and produce subtly different output.

Does WebP support animation, like GIF?

Yes, animated WebP exists and decodes in all modern browsers. The compression is dramatically better than animated GIF (often 50 to 80 percent smaller), and it supports 24-bit color and alpha transparency. Most animated GIF use cases on the web should migrate to animated WebP, animated AVIF, or video formats like MP4 and WebM.

What is jpegli and should I care?

jpegli is a JPEG encoder released by Google in 2024 that produces standard baseline JPEG files but with much better quality at the same file size. It is a drop-in replacement for libjpeg-turbo on the encode side. If you cannot change the format you serve (because of legacy clients or compatibility constraints), switching your encoder to jpegli typically saves 15 to 25 percent of file size with no client changes. It is one of the easiest performance wins available right now.

How do I check what format my images are getting served as?

Open browser DevTools, go to the Network tab, reload the page, and inspect the Content-Type response header for each image. image/webp, image/avif, and image/jxl tell you which format the browser actually received. If you are using a CDN with automatic format negotiation (Cloudflare Polish, Cloudinary, imgix), this is also where you can confirm the negotiation is working correctly.