JPG vs WebP vs AVIF: Which Image Format Should You Use in 2026?

If you ship images on the web in 2026, you have three real choices for photographic content: JPEG, WebP, and AVIF. JPEG dates from 1992 and is still everywhere. WebP is Google’s replacement, finalised in 2010 and now supported in every modern browser. AVIF is the newer AV1-based format that gets you roughly half the file size of JPEG at the same perceived quality. Comparison data, per-browser support, and a decision tree below.

Why this still matters in 2026

Images are usually 50–70% of the total weight of a webpage. Google’s Largest Contentful Paint metric — one of the three Core Web Vitals that feed directly into search ranking — is almost always an image, typically the hero. The gap between a 320 KB JPEG and a 110 KB AVIF rendering the same hero is, on a real-world mobile connection, the difference between a page that feels fast and a page that doesn’t.

Format choice has a bigger payoff than almost anything else you can change about an image. Once a JPEG is published, you can’t make it smaller without re-encoding from the source. Picking the right format up front is much cheaper than fixing it later.

JPEG / JPG: the workhorse

JPEG (the file extension is sometimes .jpg, but the format is the same) has been the default photographic image format on the web for over three decades. It’s lossy, optimised for natural images with smooth gradients, and supported by everything that touches an image — browsers, email clients, CMS exports, image editors.

Strengths:

• Universal compatibility — works everywhere, no fallback needed
• Mature tooling — every photo editor, CDN, and image library supports it
• Fast to decode — even old phones render JPEGs instantly
• Modern JPEG encoders (notably MozJPEG) produce visibly smaller files than the libjpeg defaults that most CMS exporters still ship with

Weaknesses:

• File sizes are 25–50% larger than WebP and 50–70% larger than AVIF at perceptually equivalent quality
• No transparency support — for that you’d traditionally fall back to PNG
• Visible ringing and blockiness around hard edges (text, logos overlaid on photos)
• No animation support

Where it still wins: when you need a single format that absolutely has to render in every context — old email clients, third-party embeds, printed PDFs, social network previews where you can’t control the codec — JPEG remains the safe pick.

WebP: the new sensible default

Google released WebP in 2010, but for years it was the kind of “modern format” you had to add <picture> fallbacks for. That changed when Safari shipped WebP in 2020. As of 2026, browser support is universal across modern browsers, and most email clients render it without a fuss.

WebP supports both lossy (VP8-derived) and lossless (custom) compression in one container, plus transparency and animation. The lossy mode is what you’ll use for photos; the lossless mode competes with PNG for graphics.

Strengths:

• 25–35% smaller than equivalent-quality JPEG for photos
• 25–80% smaller than equivalent-quality PNG for graphics with flat colour areas
• Transparency support, so it replaces both JPEG and PNG for many use cases
• Fast encoding — the libwebp reference encoder is quick enough to run in-browser
• Universal browser support in 2026

Weaknesses:

• Some older creative tools (especially Adobe products before 2022) won’t open .webp files natively without a plugin
• Quality at the very high end (quality 95+) is sometimes marginally worse than JPEG — but at that quality bracket, file sizes are enormous anyway
• Not a great choice for printed assets, where JPEG is still expected

Where it wins: essentially every web image that isn’t a small icon or animated GIF. If you’re choosing one format to standardise on for your CMS in 2026, WebP is the right pick.

AVIF: the state of the art

AVIF is based on the AV1 video codec (the same codec YouTube and Netflix use to ship video at lower bitrates). It landed in Chrome in 2020, Firefox in 2021, and Safari in 2022 — full support across modern browsers is now standard.

The compression is genuinely impressive: an AVIF at quality 50 looks comparable to a JPEG at quality 75, at roughly half the file size. For hero images and large product shots — where you might be shipping 200–500 KB JPEGs today — AVIF can cut that to 60–150 KB with no visible difference.

Strengths:

• 40–60% smaller than equivalent-quality JPEG
• 20–35% smaller than equivalent-quality WebP
• Excellent at high-quality settings (unlike WebP, which gets relatively worse at q90+)
• Supports HDR, wide colour gamut, transparency, and animation
• Better at handling fine detail and gradients than older formats

Weaknesses:

• Encoding is slow — server-side libaom encoders can take 10–100× longer than WebP for the same image at the same quality. This is a real operational cost if you’re encoding at upload time.
• Older browsers (anything pre-2022) don’t support it, so you need a <picture> element with a WebP or JPEG fallback if those users matter to you
• Decoding is more CPU-intensive than JPEG, which can be visible on very old phones
• Some tooling still lags — email clients, in particular, mostly don’t support AVIF in 2026

Where it wins: hero images, product photography, anything where the file is large enough that the 40–60% file-size win is worth the encoding cost. Use it as the first source in a <picture> element with WebP and JPEG fallbacks.

Side by side

These numbers will vary with image content — flat illustrations compress very differently to detailed photographs — but the rough ratios hold up across most real-world workloads.

Browser support

The headline numbers above hide a lot of variation between browsers. Here’s where each format actually ships, in stable, default-on form, as of January 2026:

WebP is safe to ship as your only modern format — every browser that matters has had it for at least five years. AVIF reaches roughly 96% of global traffic, but a <picture> fallback to WebP or JPEG still pays for itself on the long tail of older Edge installs, embedded WebViews, and corporate locked-down browsers. JPEG XL, in 2026, is still effectively a Safari-only format on the open web.

The decision tree

A practical way to pick:

1. Is this image going into an email or a printable asset? Use JPEG. The compatibility headache isn’t worth the file-size win.
2. Is this image a hero, a large product shot, or anything where it’ll be 200 KB+ as a JPEG? Use AVIF as the primary, with a WebP fallback (and JPEG behind that if you care about the long tail of older browsers).
3. Is this image a smaller in-content photo, thumbnail, or anything where 30 KB vs 50 KB doesn’t matter much? Use WebP as a single source. The marginal AVIF win isn’t worth the encoding cost or the <picture> complexity.
4. Is this a logo, icon, or flat illustration with hard edges? Use SVG if you can. If you can’t, use WebP lossless or PNG.
5. Is this an animated image? Use a video element with an MP4 or AV1 source — animated GIFs are 10–50× larger than the equivalent video.

A <picture> element with all three formats looks like this:

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

The browser picks the first format it supports. Older browsers fall through to the JPEG.

Where browser-side encoding fits

Most CMS exporters and image-processing pipelines still ship JPEGs by default in 2026 — partly because of inertia, partly because re-encoding a large library is operationally annoying. If you’re sitting on a folder of JPEGs that you need to convert to WebP or AVIF, you can do it locally without uploading them to a third-party service. Our image compressor runs the MozJPEG, libwebp, and OxiPNG encoders directly in your browser via WebAssembly — same encoders as the desktop CLIs, but no upload, no rate limit, no server.

For batch conversion of an existing library, that’s enough. For new images being added to a CMS going forward, the right fix is usually to update your build pipeline or CDN to emit modern formats automatically.

What about JPEG XL?

JPEG XL has been positioned as the “format of the future” since around 2021. It promises better compression than AVIF, fast encoding, and — its killer feature — a way to losslessly transcode any existing JPEG into a JPEG XL roughly 20% smaller, without touching the underlying image data. A one-time conversion could shrink a whole image library overnight with no quality loss and no re-encoding cost.

It’s stuck in a browser-support standoff. Chrome dropped its experimental flag in 2022 and hasn’t shipped it stable, Safari added it in 2023, Firefox has it behind a flag. As of early 2026, JPEG XL still isn’t something you can ship to the open web without polyfills.

If you’re picking a format today, pick WebP or AVIF. JPEG XL is worth checking back on if Chrome reverses course; for now, you can’t rely on it cross-browser.

In summary

• WebP for the default. It’s universally supported, encodes fast, and saves 25–35% over JPEG with no visible quality cost.
• AVIF for large, important images (hero, product shots) where the extra 20–30% file-size win is worth the encoding cost and the <picture> element ceremony.
• JPEG for emails, printable assets, and anywhere compatibility matters more than bytes.
• PNG only for graphics that genuinely need lossless compression and can’t be SVG. Otherwise, WebP lossless wins.
• GIF never, in 2026. Use a video element.

The one thing most teams could change tomorrow: stop shipping unoptimised JPEGs out of the CMS. Re-encoding a hero image with a modern encoder takes about 30 seconds and pays for itself every time the page loads.