WebP vs AVIF vs JPEG: which format should you actually use in 2026

Every few years a new image format arrives, benchmarks circulate showing it beating everything before it, and the practical question gets lost: what should you save this image as, today, for the place it is actually going?

The honest answer is that all three formats are correct for something, and the interesting differences are not the ones the benchmarks measure. Here is how they actually compare, and how to decide in about ten seconds.

The short version

If you want the rule without the reasoning: WebP for the web, JPEG when something else has to open it, AVIF when the image is large enough that the extra saving is worth the slower encode.

JPEG is not obsolete, and pretending otherwise costs you

JPEG is thirty years old and it still wins on the axis nobody benchmarks: it opens everywhere, without exception. Print shops, government upload forms, older digital photo frames, the scanner software your accountant uses, the camera roll on a phone from 2015. When an image has to leave the web and enter someone else's workflow, JPEG is the format that will not generate an email.

It also encodes extremely fast, which matters more than it sounds. If you are processing a hundred photos, an encoder that takes 40 milliseconds per image finishes while a slower one is still on the first dozen.

Where JPEG genuinely loses:

• No transparency. There is no alpha channel. A logo saved as JPEG gets a white box.
• Gradients band. Skies, studio backdrops and soft shadows develop visible steps at moderate quality, because JPEG's block transform has nothing left to spend on smooth transitions.
• Text and hard edges smear. Screenshots, charts and diagrams pick up "mosquito noise" — a halo of artefacts around every high-contrast edge.

Those three failure modes are the whole case against JPEG, and they are also a precise description of when to use something else.

WebP is the default that almost always works

WebP's real advantage is not that it is smaller — although it is, by roughly a quarter to a third at matched visual quality. Its advantage is that it is one format that covers two jobs. WebP has a lossy mode (a photo format, competitive with JPEG) and a lossless mode with alpha (a PNG replacement, typically 20–30% smaller than PNG).

That means a mixed set of images — photos, logos, screenshots, icons — can all become WebP, and each one gets an encoder appropriate to it. You stop maintaining a rule about which files are PNG and which are JPEG.

Browser support stopped being an argument years ago. Every current browser reads WebP, and has since 2020. The remaining WebP problems are outside the browser: some desktop applications, email clients and upload forms still refuse it. That is a reason to keep JPEG in the toolkit, not a reason to avoid WebP on the web.

A note on the common disappointment: converting an already-compressed JPEG to WebP often saves much less than the headline numbers, sometimes nothing at all. That is not WebP underperforming. The original JPEG already discarded the detail that both formats would have discarded; you are compressing what is left. The savings quoted in comparisons are measured from an uncompressed original, which is the fair test but not the one you are usually running. If you want the real number for your own files, run them through the converter and compare — it takes a few seconds and beats any benchmark done on someone else's photographs.

AVIF is excellent and it is not free

AVIF is genuinely the strongest of the three on compression. Derived from the AV1 video codec, it holds detail at bitrates where JPEG has fallen apart, and it is dramatically better at the two things JPEG is worst at: smooth gradients and flat colour. A sky that bands badly as an 80-quality JPEG can be clean as an AVIF at half the file size.

The costs are real.

Encoding is slow. Depending on the effort setting, AVIF encoding can take ten to fifty times longer than JPEG for the same image. On a batch of two hundred product photos that is the difference between a coffee and an afternoon. On a single hero image it does not matter at all — which tells you exactly where AVIF belongs.

Support is good but not universal. Current versions of every major browser decode AVIF. Older installed versions, some in-app browsers, and a long tail of non-browser software do not. If your delivery path can serve a fallback, this is a non-issue; if it cannot, it is a hard blocker.

Small images barely benefit. AVIF carries more container overhead than JPEG. Below roughly 10 KB — icons, tiny thumbnails, avatars — the format's fixed costs eat the compression advantage, and a WebP or even a PNG can come out smaller. AVIF's advantage grows with image size, which is why it shines on full-width photography and does nothing for a 48-pixel avatar.

How to actually decide

Three questions, in order.

1. Does anything other than a browser need to open it?

If yes — an upload form, a print shop, a colleague's desktop software, a system you do not control — use JPEG, or PNG if it needs transparency. This question comes first because it is a hard constraint, and the other two are optimisations.

2. Does it need transparency?

If yes, JPEG is out. Use WebP lossless for logos, icons and UI assets with hard edges, or WebP lossy with alpha for a cut-out photograph, which is much smaller than a lossless version and usually indistinguishable. PNG remains correct when the file has to be universally readable — see the point above about upload forms.

If you are producing cut-outs, this is worth knowing before you start: removing a background produces an alpha channel, and saving the result as JPEG silently flattens it onto white. That is the single most common way people lose the transparency they just paid for.

3. How big is the image, and how many are there?

• One or a few large images — hero banners, full-width photography, anything over about 1200 pixels wide: AVIF if your delivery supports it, WebP otherwise. The encode cost is paid once and the bandwidth saving is paid on every view.
• Many images — a catalogue, a gallery, a batch export: WebP. Encode time is what you are optimising for, and WebP gives you most of AVIF's saving at a small fraction of the cost.
• Small images — icons and thumbnails under about 10 KB: WebP, or PNG if it must be universal. AVIF's overhead is not worth it at this size.

The thing that beats format choice

Formats are the last 30%. The first 70% is dimensions.

An image displayed at 800 pixels wide and stored at 4000 pixels wide is carrying twenty-five times the pixel data it will ever show. No format choice recovers that. Converting it from JPEG to AVIF might halve a 3 MB file to 1.5 MB; resizing it to the size it is displayed at takes the same file to about 90 KB, and then the format choice takes it to 60 KB.

So the order of operations is:

1. Resize to the largest size it will actually be displayed at, plus a 2× allowance if it needs to stay sharp on high-density screens.
2. Choose the format using the three questions above.
3. Compress at quality 75–85 and look at the result. That range is the knee of the curve for every lossy codec — meaningfully smaller than 95, visually identical in almost every case.

Doing these in the other order — compressing hard, then resizing — throws away detail twice and produces a worse image at a similar size.

A few things that are commonly wrong

"Lossless means better quality." Lossless means identical to the input. If the input is a quality-60 JPEG, a lossless conversion faithfully preserves quality-60 artefacts in a much larger file. Lossless is the right choice for masters, screenshots and line art; it is not a quality upgrade.

"Re-saving at high quality restores the image." Compression artefacts are part of the pixel data now. Re-encoding at quality 100 preserves them exactly and produces a bigger file. There is nothing to recover. Genuine detail reconstruction is a different operation altogether — an upscaling model inferring plausible detail, not a codec recovering real detail — and it is worth knowing which one you are asking for.

"WebP is lossy." WebP is both. So is AVIF. The format name does not tell you which mode a file used, which is exactly why "convert to WebP" is not a complete instruction.

"Just use the highest quality setting." Quality 100 in a lossy codec is not lossless. It is the most expensive lossy setting, storing artefacts at enormous cost. If you want lossless, ask for lossless.

Where this leaves you

For most people, most of the time, on the web: WebP at quality 80, resized to the display size. It is small, it handles transparency, everything reads it, and it encodes fast enough to run over a folder full of images.

Reach for AVIF when the image is large and prominent enough that another 30% matters. Reach for JPEG the moment the file has to work somewhere you do not control.

You can test all of this on your own files without uploading anything. OpusImg's format converter and compressor run entirely in your browser using WebAssembly codecs, so you can compare real numbers on real images and never send them anywhere — which is the only benchmark that has ever mattered. Your images, your eyes, your bandwidth.