WebP, AVIF or JPEG: picking the right image format

The short answer

You probably came here for one line, so here it is.

Use WebP. It is smaller than JPEG at the same visual quality, it handles transparency, it encodes fast, and roughly 96% of browsers in use today support it. Nobody has ever regretted shipping WebP.

Use AVIF when the bytes genuinely matter and you can afford the encode time. Hero images, large photography, anything above the fold on a mobile-first store. Ship a WebP or JPEG fallback alongside it.

Use JPEG when something downstream is fussy. Email, a marketplace uploader, a supplier portal, a print shop, a colleague's ancient copy of something. JPEG is still the format that never asks a question.

Use PNG only for transparency or pixel-exact graphics, and reach for WebP first even then.

Use SVG for logos and icons, which is not the same competition and we will get to why people keep entering it.

That's it. If you have a job to do, go do it. The rest of this is the reasoning, the support gaps, and the bit where you measure your own images instead of trusting anyone's numbers, ours included.

AVIF: smallest files, slowest encode

AVIF is a still image wrapped in the AV1 video codec. It is the most efficient of the four by a clear margin, and on photographic content it is not close. It also does 10-bit colour and HDR, which matters if you shoot product photography properly and care that the deep blues in a hero shot don't band.

The catch is encode time. AV1 was designed to spend a lot of CPU compressing a frame once so that millions of people can cheaply decode it later. That trade is excellent for a streaming service and merely annoying for you, sitting there watching a progress bar on a batch of 200 product photos. It is slower than WebP by a wide margin, and slower than JPEG by an embarrassing one.

Browser support is now genuinely fine. Chrome has shipped it since August 2020, Firefox since October 2021, Safari since 16.4 in March 2023, and Edge since version 121 in January 2024. That lands at roughly 95% of global browser usage.

Where support still bites is everywhere that isn't a browser:

• Older iOS. The remaining gap is mostly people on iOS before 16.4, and on a consumer store that population is not zero.
• Email clients. Treat AVIF in email as unsupported. Outlook and a long tail of clients will show nothing at all.
• Tooling. Design apps, older CMS uploaders, marketplace feeds, image plugins and internal admin tools all lag browsers badly. Shopify, Google Merchant Center and a supplier's ERP each have their own opinion, and the one you care about is usually the one that says no.
• Animation. Animated AVIF exists on paper and is patchy in practice. Firefox still has an open bug for image sequences. Don't build anything on it.

So AVIF is a "yes, with a fallback" format, not a "yes, replace everything" format.

WebP: the safe default nobody regrets

WebP is the boring, correct answer for the overwhelming majority of images on a website.

It compresses meaningfully better than JPEG at the same perceived quality (Google's own published figure is 25-35%, and real photos land all over that range). It does lossy and lossless. It does transparency, which JPEG has never managed. It does animation, which is the polite way to stop shipping GIFs. It encodes fast enough that batching a few hundred images is not a coffee break.

Support is effectively universal on anything made this decade: Chrome since 32, Firefox since 65, Edge since 18, Safari since 16 on desktop and 14 on iOS. Around 96% of global usage, with the remainder being Internet Explorer and genuinely ancient devices.

Tooling support is the real reason to prefer it over AVIF as a default. WebP has been around long enough that the CMSes, the plugins, the marketplace feeds and the design apps all know what it is. AVIF hasn't. If you ship one format and you don't want to think about it again, ship this one.

JPEG: still correct more often than people admit

JPEG is thirty-odd years old and people talk about it like it's embarrassing. It isn't. It is correct in three situations that come up constantly.

When the destination is out of your control. An email campaign, a marketplace listing, a supplier portal, a partner's media kit, a printer. JPEG works everywhere and always has. Sending a WebP to someone else's system and hoping is not a strategy.

When the image is a photo and the file is already small. Below about 30KB the format overhead and the perceptual difference both shrink towards nothing. Converting a 12KB thumbnail from JPEG to AVIF to save 3KB, then serving a <picture> element with three sources to do it, is work you will maintain forever for a saving nobody will measure.

When encode speed is the constraint. A user uploading photos from their phone and waiting for the result is a different problem to your build pipeline running overnight.

One thing worth doing: if you are staying on JPEG, use a good encoder. MozJPEG produces noticeably smaller files than the default encoder at the same quality setting, and it costs you nothing because the output is still a plain JPEG that everything can read. Quality 75-80 is usually indistinguishable from the original on a photo.

PNG, and when transparency is the only reason

PNG is lossless. That is its whole personality, and it is a good one for screenshots, UI graphics, diagrams, and anything with hard edges and flat colour where JPEG's ringing artefacts look awful.

For photographs it is the wrong tool and the file sizes are brutal. A photo saved as PNG is routinely five to ten times the size of a good JPEG of the same picture, for a difference no human eye will find.

Here is the part people miss: if you reached for PNG because you needed transparency, WebP does transparency too, losslessly if you want, at a fraction of the size. The only reasons left to keep a PNG are a downstream system that demands one, or a genuine need for pixel-exact lossless output.

Favicons are their own special case with their own rules, and we wrote those up separately in favicon design best practices.

SVG is not in this race

SVG keeps turning up in "best image format" comparisons and it shouldn't, because it isn't the same kind of thing. JPEG, WebP, AVIF and PNG are grids of pixels. SVG is a set of drawing instructions the browser executes. Asking whether SVG compresses better than AVIF is like asking whether a recipe weighs less than a cake.

Why people keep entering it in the race: SVG really is the right answer for logos, icons, simple illustrations and anything that must stay sharp at any size, and those things do appear on the same page as photographs. So it wins a comparison it was never in, and someone concludes it is the best format, and then someone tries to save a product photo as SVG.

That last part is where it goes wrong. Export a photo from a design tool as SVG and you get a giant XML wrapper around a base64-encoded PNG, which is bigger than the PNG was, in a format that pretends to be vector. If your image came from a camera, SVG is not the answer. If it came from a pen tool, it usually is.

Two things worth knowing if you do ship SVG: gzip it (they are text, so they compress beautifully, and .svg.gz or server-side compression is free) and sanitise anything you didn't author, because SVG can contain scripts.

Real numbers, on your own photo

We are not going to print a table of savings for "one photo" and let you plan around it, because that number is close to meaningless. The gap between formats swings wildly depending on the image. A flat studio shot on white behaves nothing like a detailed outdoor scene with foliage, and either can beat the other's typical ratio by a mile.

The shape of the result is stable, though, and it goes like this. Take any photograph and encode it four ways at a quality that looks the same to your eye:

• PNG will be the largest by a long way, usually several times everything else.
• JPEG is the baseline everyone else gets measured against.
• WebP lands meaningfully below JPEG. Google's published range is 25-35% smaller and that broadly holds up.
• AVIF lands meaningfully below WebP again, with the biggest wins on large, detailed, photographic content and the smallest wins on small or flat images.

The ordering almost never changes. The size of each gap changes constantly.

So measure yours. Open Unwrite Images, drop in the single photo that matters most on your site (the homepage hero, the best-selling product's main shot), and export it at the same quality as JPEG, WebP and AVIF. That gives you a number for your images rather than someone else's, and it takes about a minute. The encoding runs in your browser, so the file never goes anywhere, which is the whole point of the tool.

Fallbacks, briefly

If you ship AVIF, ship a fallback. The mechanism is <picture>, the browser picks the first source it can decode, and it looks like this:

<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="Copper kettle on a stovetop" width="1200" height="800" />
</picture>

Order matters, best format first. The <img> at the end is not optional, it is the element that actually renders and the one that carries your alt text, width and height. Keep the dimensions on it or you will hand yourself a layout shift.

If you are on a platform with an image CDN (Shopify, Cloudflare Images, Next.js and friends), it is probably already doing format negotiation for you based on the Accept header, which is the same idea done server-side and with less markup. Check before you hand-roll it.

Do it locally, not on a converter site

Most "convert to WebP online" sites work by taking your file, putting it on their server, converting it there, and giving you a link. For a stock photo, fine. For unreleased product photography, a client's brand assets, or anything with a person in it, less fine. Images carry EXIF too, which can mean GPS coordinates and device serial numbers riding along with a photo you thought was just pixels.

You don't need a server for any of this. The same codecs the desktop tools use (MozJPEG, OxiPNG, WebP, AVIF) are compiled to WebAssembly and run at close to native speed inside a browser tab, which is the architecture behind every tool on this site. Unwrite Images compresses, resizes, converts and batches with all of that running locally. Open the Network tab while you use it if you want to watch nothing leave.

The one-line version, again

WebP by default. AVIF with a fallback when the bytes matter. JPEG when someone else's system is involved. PNG for transparency and hard edges, and only if WebP won't do. SVG for things you drew, never for things you photographed.