AVIF vs WebP vs JPEG XL: Choosing the Right Image Format in 2026

Images are, for most websites, the single largest contributor to page weight — and therefore to load times, bandwidth bills, and Core Web Vitals scores. Choosing the right format is one of the highest-leverage performance decisions you can make, often cutting image payloads in half with no visible quality loss. Yet the landscape has gotten genuinely confusing: alongside the venerable JPEG, PNG, and GIF, we now have WebP, AVIF, and JPEG XL, each with different strengths, compression characteristics, and — crucially — different browser support.

This guide cuts through the confusion. We’ll compare every relevant format on the dimensions that matter (compression, transparency, animation, color depth, browser support), explain the lossy-versus-lossless distinction that underlies all of them, and give you a clear, defensible strategy for what to use in 2026. The short version is encouraging: with the <picture> element you don’t have to pick one format — you can serve the best one each browser supports and fall back gracefully. But understanding why gets you a far better result than copying a snippet.

The classics: JPEG, PNG, and GIF

Before the modern formats, three classics defined web imagery, and they’re still everywhere.

JPEG (1992) is the workhorse of photographs. It uses lossy compression — discarding data the eye is least likely to miss — to achieve small files, with a quality slider trading size against fidelity. Its limitations: no transparency (no alpha channel), visible artifacts at low quality (blocky “mosquito noise”), and compression that’s now decisively beaten by newer codecs. JPEG remains valuable for one reason: universal compatibility. Everything, everywhere, opens a JPEG.

PNG (1996) is lossless — it reproduces every pixel exactly — and supports transparency. That makes it ideal for graphics, logos, screenshots, and anything with sharp edges or text, where JPEG’s artifacts would be ugly. The cost is large files for photographic content, because lossless compression can’t match lossy for photos.

GIF (1987) survives almost entirely for one feature — animation — despite being technically obsolete (256-color palette, poor compression). For animation, modern formats (animated WebP, AVIF, or just video) are far superior; GIF persists out of habit and ubiquity.

These three established the baseline: lossy-small-no-transparency (JPEG), lossless-with-transparency (PNG), and animated (GIF). The modern formats improve on all three axes at once.

WebP: the pragmatic default

WebP, from Google, is the format that finally moved the web past JPEG and PNG for most use cases. Its pitch is compelling: it does everything the classics do, better.

• Lossy WebP is typically 25–35% smaller than JPEG at equivalent quality.
• Lossless WebP is usually smaller than PNG.
• It supports transparency (alpha channel) like PNG.
• It supports animation like GIF, at a fraction of the size.

In other words, WebP is a single format that replaces JPEG, PNG, and GIF, with better compression than all three. Its decisive advantage in 2026 is universal browser support — every current browser handles WebP. This combination of broad capability and total support makes WebP the pragmatic default: if you adopt just one modern format, make it WebP. Converting your existing JPEGs and PNGs to WebP is a quick, low-risk win, easily done with an image format converter.

AVIF: the compression champion

AVIF is derived from the AV1 video codec, and it brings video-grade compression to still images. On the dimension that matters most — file size — it’s the leader: AVIF images are frequently around 50% smaller than JPEG at comparable quality, beating even WebP. It also supports capabilities the older formats lack:

• Transparency (alpha channel).
• HDR and wide color gamut (more than sRGB), so vivid, high-dynamic-range images look better on capable displays.
• Higher bit depth, reducing banding in gradients.
• Animation.

The trade-offs are real but manageable. AVIF encoding is slower and more CPU-intensive than JPEG or WebP — a build-time concern, not a runtime one, since decoding (what users do) is fast. And its browser support, though now broad, arrived more recently than WebP’s, so a small slice of older browsers can’t decode it. The answer to both is the fallback strategy below: serve AVIF where it’s supported and WebP/JPEG elsewhere, getting AVIF’s dramatic savings for the majority while losing nothing for the minority. For photo-heavy pages and hero images — where the byte savings most affect LCP — AVIF is the strongest choice.

JPEG XL: the promising format that stalled

JPEG XL (JXL) has, on paper, the most impressive feature set of any modern format:

• Excellent compression, competitive with or exceeding AVIF in many scenarios.
• Lossless JPEG transcoding — it can re-encode an existing JPEG losslessly at roughly 20% smaller size, a killer feature for migrating huge existing image libraries without quality loss.
• Progressive decoding (a low-res preview appears first, then sharpens), great for perceived performance.
• High bit depth, wide gamut, and both lossy and lossless modes in one format.

So why isn’t it everywhere? Browser support has been inconsistent and contentious. Some browsers shipped it behind flags, removed it, or declined to support it natively, which means you cannot rely on a website visitor’s browser to decode JXL. For a web format, that’s disqualifying as a default — you can’t serve a format a large share of browsers won’t render. JPEG XL therefore lives, for now, in professional, archival, and application contexts where the environment is controlled, rather than on the open web. It remains the most technically promising format and may yet gain traction, but in 2026 it is not a safe default for websites. Watch it; don’t bet your production pipeline on it yet.

Lossy vs lossless: the distinction under everything

Every format decision rests on this choice, so it’s worth stating clearly:

• Lossy compression (JPEG, lossy WebP, lossy AVIF, lossy JXL) permanently discards image data to shrink files dramatically. A quality setting controls how aggressive the discarding is; above roughly 80% quality, the loss is generally invisible to the eye. Use it for photographs, where minor, imperceptible imperfections are an acceptable trade for big savings.
• Lossless compression (PNG, lossless WebP, lossless AVIF) reduces file size without discarding anything — the original reconstructs perfectly. Files are larger than lossy. Use it for graphics, logos, screenshots, and images with text or sharp edges, where lossy artifacts would be visible and unacceptable.

A common mistake is converting a photo to PNG (bloating it) or a sharp-edged screenshot to low-quality JPEG (introducing ugly artifacts around the text). Match the compression type to the content, not out of habit.

One more place this matters: animation. The animated GIF, despite being everywhere, is a terrible way to ship motion — its 256-color palette banding and weak compression make even short clips enormous. Animated WebP and AVIF compress dramatically better at far higher quality, and for anything longer than a couple of seconds, a real video format (MP4/AV1 in a <video> element) beats all of them by an order of magnitude. If you’re still serving GIFs for animation, converting them to a modern format or short video is one of the easiest large wins available — a multi-megabyte GIF often becomes a few hundred kilobytes with better visual quality.

The 2026 strategy: serve the best, fall back gracefully

You don’t have to choose a single format for your whole site. The <picture> element lets you offer several and let the browser pick the best one it supports:

<picture>
  <source type="image/avif" srcset="/hero.avif">
  <source type="image/webp" srcset="/hero.webp">
  <img src="/hero.jpg" alt="..." width="1600" height="900">
</picture>

The browser evaluates the <source> elements top to bottom and uses the first format it can decode, falling back to the <img> for anything that supports none of them. Order them by preference — AVIF first (smallest), WebP next (broadly supported, still small), JPEG/PNG last (universal). The type attribute lets the browser choose without downloading, so there’s no wasted bandwidth. This pattern gives every visitor the smallest format their browser can handle while guaranteeing nobody sees a broken image — the best of all worlds.

Note the width and height on the <img>: always include intrinsic dimensions so the browser reserves layout space and avoids the cumulative layout shift (CLS) that hurts Core Web Vitals.

Format choice is only half the win

Here’s the point that’s easy to miss: choosing AVIF over JPEG is worthless if you’re shipping a 4000px image into an 800px slot. The two biggest image-performance levers are format and dimensions, and dimensions are often the larger one. A perfectly-encoded AVIF at 4000px wide is still far heavier than a properly-sized 800px (×2 for retina = 1600px) image in any format.

So the complete workflow is:

1. Resize the image to roughly its display size (times device pixel ratio), using srcset to serve different sizes to different screens. An image resizer does this.
2. Compress at an appropriate quality (around 80% for lossy is the usual sweet spot). An image compressor handles this.
3. Convert to modern formats and serve them via <picture>. An image format converter produces the AVIF/WebP variants.
4. For vector graphics — icons, logos, illustrations — keep them as SVG, which is resolution-independent and tiny; optimize with an SVG optimizer rather than rasterizing them at all.

Format conversion alone might cut your image weight 30–50%; resizing first can cut it 80%+. Do both.

A quick reference

Encoding settings: quality, effort, and how to tune them

Choosing a format is the first decision; how you encode into it is the second, and it’s where a lot of quality and size is won or lost. Each modern format exposes knobs that trade encoding time, file size, and visual quality.

The most important knob is quality (for lossy modes). It’s tempting to crank it to 90+ “to be safe,” but the returns diminish sharply: the jump from 60 to 80 is usually invisible and saves real bytes, while 80 to 95 multiplies file size for differences only a pixel-peeper notices. For photographic content, an 80% target (or its per-format equivalent) is the usual sweet spot. Always compare the compressed result against the original at 100% zoom before committing — the right quality is “the lowest setting at which you can’t see the difference,” and that varies by image.

AVIF and WebP also expose an effort or speed setting that controls how hard the encoder works. Higher effort produces smaller files for the same quality but takes longer to encode. Because encoding happens once at build time and decoding happens millions of times in users’ browsers, it’s almost always worth spending the extra encoding seconds for a smaller file — the cost is paid once, the benefit is paid forever. In an automated build pipeline, set effort high; only drop it if encode time becomes a genuine bottleneck.

A subtlety worth knowing: don’t re-encode a lossy image as lossy repeatedly. Each lossy pass discards data, and the losses compound — a JPEG converted to WebP and back to JPEG accumulates artifacts. Always encode from the highest-quality original you have (ideally a lossless master) rather than from an already-compressed file. If you’re converting a library of existing JPEGs, you’re stuck with their baseline quality, but at least don’t add further lossy generations on top.

Responsive images: srcset and sizes done right

Serving modern formats is only half the responsive-image story; the other half is serving the right size. The srcset and sizes attributes let the browser pick the best resolution for each device, which — combined with format selection — is how you achieve genuinely optimal delivery.

srcset lists several versions of an image at different widths, and sizes tells the browser how wide the image will be displayed at different breakpoints, so it can choose the smallest file that still looks sharp:

<img
  src="/photo-800.jpg"
  srcset="/photo-400.jpg 400w, /photo-800.jpg 800w, /photo-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="600" alt="...">

Here a phone downloads the 400px version, a desktop the 800px, and a retina desktop the 1600px — each gets a file appropriate to its screen, rather than everyone downloading one giant image. Combine this with <picture> for format selection and you have the complete modern image element: the right format at the right size for every visitor. Generating the size variants is mechanical work an image resizer handles, and most build tools and image CDNs can produce the full matrix automatically.

The payoff compounds: format selection might cut bytes 30–50%, and resolution selection cuts them again for the majority of users on smaller screens. Together they routinely reduce real-world image payloads by 70% or more compared to shipping a single large JPEG to everyone.

Automating the pipeline

Doing all of this by hand for every image doesn’t scale. In production, image optimization is automated, and there are three common approaches. Build-time generation (via your bundler or a static-site image plugin) produces the format and size variants as part of your build — ideal for content known ahead of time. Image CDNs transform images on the fly from a single source, serving the optimal format and size per request based on the browser’s Accept header and device, with results cached at the edge — ideal for user-uploaded or dynamic content. Hybrid setups combine both. Whichever you choose, the principle is the same: store one high-quality master per image and derive everything else automatically. Manual conversion with an image format converter and compressor is perfect for one-off needs and for understanding what the automation should produce, but the pipeline itself should be automatic so that “optimize the images” is never a step anyone has to remember.

Conclusion

The modern image-format landscape rewards a simple strategy. Make WebP your pragmatic baseline — universally supported and substantially smaller than the classics. Serve AVIF on top of it for your heaviest images, where its ~50% savings most improve load time and Core Web Vitals, using the <picture> element to fall back to WebP and then JPEG/PNG so every browser is covered. Keep an eye on JPEG XL — technically superb, but held back by inconsistent browser support, so not yet a safe web default. Match lossy versus lossless to the content, not habit. And never forget that format is only half the win: resize images to their display size before you ever convert them, because the cheapest byte is the one you never sent. Audit one image-heavy page today — are you serving AVIF/WebP, sized to the slot, via <picture> with dimensions set? Fix that, and you’ll likely halve the page’s image weight without anyone noticing a difference except your load times.