JPG vs WebP vs AVIF: Best Image Format in 2026 (Real Benchmarks)

I keep getting asked some version of "should I just use WebP for everything now?" and the honest answer is "almost, but actually no." This post is the data behind that "almost no," from a benchmark I ran across 47 real images last week — product photos, screenshots, illustrations, photography, and the kind of generic stock imagery a marketing page has 12 of.

Short version of the conclusion, for people who like the answer before the work:

AVIF is 45–55% smaller than JPG at visually-equivalent quality. Use for hero images on sites where you control the audience's browser.
WebP is 25–35% smaller than JPG at visually-equivalent quality. Use as the default for almost everything else.
JPG is still the right answer for one case: galleries where you need every browser ever made to load every image without a fallback chain.
PNG stays the right answer for screenshots with text and for anything with hard-edged transparency. WebP-lossless and AVIF-lossless are technically better, but the wins are smaller than on photos and the tooling story is rougher.

If you want to run the same comparison on your own images, image-compressor-local does JPG/WebP/AVIF side-by-side in the browser without uploading anything.

The Benchmark

Source set: 47 images, 4 categories.

| Category | Count | Source quality | |-----------------|------:|----------------| | Product photos | 14 | 24-megapixel mirrorless, RAW → JPG export at quality 95 | | Screenshots | 12 | macOS native PNG at 2x | | Illustrations | 11 | Vector exports flattened to PNG at 2000 px | | Generic photos | 10 | Stock library at original size |

Each image was re-encoded to JPG (quality 80), WebP (quality 80), and AVIF (quality 60, which is roughly visually equivalent to WebP 80 in subjective tests). All sizes measured after encoding, not after additional gzip or brotli (which barely affects already-compressed image bytes).

| Category | JPG avg | WebP avg | AVIF avg | WebP vs JPG | AVIF vs JPG | |-----------------|--------:|---------:|---------:|------------:|------------:| | Product photos | 412 KB | 286 KB | 201 KB | -31% | -51% | | Screenshots | 198 KB | 124 KB | 89 KB | -37% | -55% | | Illustrations | 156 KB | 92 KB | 71 KB | -41% | -54% | | Generic photos | 348 KB | 248 KB | 174 KB | -29% | -50% |

Three takeaways the table makes obvious:

AVIF's lead over WebP is bigger than WebP's lead over JPG. The compression generation jumped further the second time.
The biggest wins are on screenshots and illustrations — categories with large flat regions where the newer codecs' improved prediction shines.
Even the smallest WebP win (29% on generic photos) is well worth a one-line build change.

Browser Support in 2026

JPG: every browser ever made. No discussion.
WebP: Chrome since 2010, Firefox since 2019, Safari since iOS 14 (2020) and macOS Big Sur. Effectively universal in 2026. The last meaningful gap closed five years ago.
AVIF: Chrome since 2020, Firefox since 2021, Safari since 16 (2022). The remaining gap as of 2026 is users still on Safari 15 and below — almost nobody, but in some enterprise environments stuck on old macOS versions, it's a real percentage.

The practical implication: WebP no longer needs a fallback <picture> element for general audiences. AVIF still does if you want to serve every visitor.

When Each Format Wins

AVIF wins when:

You have a small number of high-value images (hero, above-the-fold) and care intensely about Core Web Vitals. A 200 KB hero versus a 400 KB hero is half a second on slow 3G.
Your audience is on modern devices (consumer web, gaming, SaaS).
You can afford the encode cost. AVIF encoding is 5–10x slower than WebP, which matters if you're regenerating thousands of images per build.

WebP wins when:

You want one format for all your raster assets and you don't want a fallback chain.
You have a build pipeline that needs to be fast (CI matters more than CDN bytes).
You're optimizing screenshots and UI graphics where AVIF's marginal win is smaller than its tooling complexity.

JPG wins when:

You're serving the very long tail of legacy browsers (still relevant in some emerging markets and in enterprise contexts pinned to old corporate images).
You're handing a file to a non-technical person who needs to open it in Preview/Windows Photos without ceremony.
You're embedding in a context (email, an old CMS, a print PDF pipeline) where the consuming software hasn't caught up.

PNG still wins when:

The image is mostly text — screenshots of code, terminal output, documentation. Lossy formats produce ugly halos around sharp text edges that AVIF mitigates but PNG eliminates.
You need precise alpha transparency, especially with hard edges (UI sprites, icons).
For a quick PNG-to-data-URL workflow (embedding in CSS or HTML email), base64-image-converter handles the encoding without leaving the browser.

The Workflow I Settled On

For Toolora, after this benchmark:

Photos on blog posts and tool screenshots: AVIF at quality 60, with WebP at quality 80 as the <picture> fallback. The AVIF saves 50% over JPG on the cover image alone.
UI icons and favicons: still SVG where possible, PNG where SVG can't represent the asset. The favicon generator emits PNG variants at the sizes browsers actually request.
One-off images in markdown drafts: WebP at quality 85. Saves enough size that I don't have to think about it, supported everywhere I publish.
Color palette extraction from inspiration images: image-color-extractor, which works on any of the three formats.

A Note on Quality Settings

The numbers above use JPG 80, WebP 80, AVIF 60. These are roughly visually equivalent — meaning a careful viewer comparing side-by-side at 100% magnification would not see clear differences. They are not numerically equivalent — quality 80 in JPG is a different operation from quality 80 in AVIF.

The temptation is to set AVIF at 80 because "higher must be better." Don't. AVIF at 80 is overkill for almost everything, and you give up most of the size advantage. Start at 60, view the output at 100%, and only raise if you can see degradation.

The same applies in reverse: pushing JPG below 70 gets you visible blocking artifacts; pushing WebP below 70 gets you visible smearing on detailed textures. Each codec has a different sweet spot.

TL;DR for 2026

If I had to give one rule for the next two years: AVIF for above-the-fold, WebP for everything else, fall back to JPG only when you have a specific reason. That covers 95% of decisions and saves you the rest of the day for actual work.

Related tools

Made by Toolora · Updated 2026-05-26