JPEG vs WebP vs AVIF - Differences and How to Choose an Image Format

How JPEG, WebP, and AVIF Work and Where Each Excels

When choosing an image compression format, the three that cause the most hesitation are JPEG, WebP, and AVIF. All three are used mainly for lossy compression, shrinking files while keeping the image looking almost the same, but they were born in different eras with different internals, so they differ in the kinds of images they handle well and the features they offer.

JPEG has a long history and opens almost everywhere. MDN's image file type guide (updated August 2026) still describes it as the most popular choice for lossy compression of still images, and lists every version of Chrome, Edge, Firefox, Opera, and Safari as supporting it. It splits the image into 8x8-pixel blocks, converts each into frequency components, and stores the high-frequency detail the eye barely notices at lower precision to save space. It suits photographs with continuous tones, but it cannot store transparency (an alpha channel), and heavy compression tends to produce visible block edges and smudging around text.

WebP was developed by Google and applies the key-frame coding of the VP8 video codec to still images. Because it uses predictive coding, estimating each block from its neighbors and storing only the difference, it tends to be smaller than JPEG at the same quality, and it supports both lossy and lossless modes as well as transparency and animation. Google's WebP documentation (updated August 2025) states that lossless WebP images are 26% smaller than PNGs and lossy images are 25-34% smaller than comparable JPEGs at equivalent quality. One limit is that a WebP image can be at most 16383 pixels on a side (WebP FAQ, updated February 2026).

AVIF stands for AV1 Image File Format, defined by the Alliance for Open Media (AOMedia); it packs the still-image coding of the AV1 video codec into a HEIF-family container (AVIF specification v1.2.0, October 2025). Using variable-size blocks larger than JPEG's 8x8 together with advanced prediction, it is efficient on flat color areas and large images, and it supports 8-, 10-, and 12-bit color depth, transparency, HDR, and image sequences (animation) (MDN, updated August 2026). Being royalty-free is one more reason its adoption on the web has grown.

In short: JPEG when compatibility comes first, WebP when you want a balance of compatibility and compression, and AVIF when compression ratio and features matter most. The following sections look at how these differences show up in quality, file size, browser support, and use cases.

Quality vs. File Size - What Drives Compression Efficiency

A single figure such as "AVIF is X% smaller than JPEG" actually varies a great deal with conditions. Even within one format, the compression ratio moves up and down with the quality setting, the image content, the resolution, and the encoder implementation and its settings, so whenever you see a number, check the conditions behind it.

Quality setting: In lossy compression, lowering the quality parameter shrinks the file, but past a certain point the degradation becomes visible. The quality parameter means something different in each format, so giving JPEG and WebP the same quality value does not produce the same visual quality. A fair comparison requires matching quality first, using a metric such as SSIM or visual inspection, and then comparing sizes.

Image content: Smooth regions such as sky gradients and skin are easy to predict and compress well in every format. Fine textures such as fabric, wood grain, or gravel are hard to predict; the ratio drops, and heavy compression can flatten the detail into a painted look. In screenshots containing text and sharp lines, JPEG tends to produce ringing, a halo-like smudge around edges, and needs a high quality setting to keep the same appearance.

Resolution: The large variable-size blocks that AVIF uses can represent wide flat areas at once, so it tends to gain more on larger images. On small thumbnails the gap between formats tends to narrow, which makes it worth checking by size.

Encoder and speed setting: Even for the same format, results change with the encoder implementation and its speed (effort) setting. In general, the longer the encoder searches, the better the ratio; favoring speed lowers it. AVIF encoding tends to take longer than JPEG or WebP, which is fine for batch conversion at build time but may call for tuning the speed setting or deferring the work when converting right after upload. Decode (display) cost also differs by format, so on image-heavy pages it is worth combining decoding="async" with lazy loading.

The takeaway: read any compression figure as one example under its own conditions, and verify with your own images. The steps are described below under "Testing With Your Own Images".

Browser Support Today and How to Provide Fallbacks

A high compression ratio means nothing if the visitor's browser cannot display the image. According to caniuse data (updated August 2026), support weighted by global usage share is about 96% for WebP. AVIF has reached about 95%, and the current versions of Chrome, Edge, Firefox, and Safari all display both formats.

The timing of that support differs, however. In the same data, Safari gained full WebP support in version 16.0 (versions 14.0 through 15.6 required macOS 11 or later) and full AVIF support in version 16.4, so visitors on older Safari need a fallback. Animated AVIF (image sequences) arrived later than still images; the data marks Safari 16.1 through 16.3 and Firefox 93 through 112 as supporting still images only (Safari 16.0 and earlier has no AVIF support at all).

The practical answer is the picture element: list candidates from the newest format down and place JPEG or PNG last. The browser picks the first source it can display, so you do not have to write code that detects support and branches.

<picture>
  <source type="image/avif" srcset="photo.avif">
  <source type="image/webp" srcset="photo.webp">
  <img src="photo.jpg" alt="Description of the photo">
</picture>

Some CDNs and image transformation services read the request's Accept header and return the best format on the server side. This lets you migrate without changing the HTML, but keep in mind at design time that the cache is then split by Accept header.

Choosing by Use Case - Photos, Illustrations, Transparency, Animation

Which format fits depends on the kind of image. Here is how to think about each use case.

• Photos: The classic territory where lossy compression works well. The basic pattern is a three-tier setup with AVIF as the first choice, WebP second, and JPEG as the final fallback. On heavily textured photos, pushing AVIF quality too low can flatten detail, so start with a conservative quality setting and refine by eye.
• Illustrations and flat design: Large uniform color areas let the predictive coding of WebP and AVIF work well. When smudged lines are unacceptable, choose a lossless mode instead, using lossless WebP (often smaller than PNG) or PNG.
• Screenshots and images containing text: Keeping the text edges crisp is the top priority. If you go lossy, avoid JPEG and use WebP or AVIF at high quality; otherwise choose PNG or lossless WebP.
• Transparent images (icons, cut-out product photos): JPEG cannot store transparency, so PNG was long the default. Both WebP and AVIF offer lossy compression with an alpha channel, so migrating from PNG often yields a large size reduction, and product images on e-commerce sites are worth tackling first.
• Animation: Animated WebP is the standard replacement for GIF, and the MDN guide likewise recommends considering WebP, AVIF, or APNG for animation. AVIF image sequences are supported by the specification, but as noted in the previous section browser support arrived at different times, so for longer clips also consider a video element with MP4 or WebM.
• HDR and high bit depth: The format for which the MDN guide (updated August 2026) lists 8-, 10-, and 12-bit color depth and HDR support is AVIF; WebP is 8-bit. For uses that value tonal range, such as delivering photographic work, this is a reason to choose AVIF.

Set migration priorities by impact and effort. For many sites the efficient order is (1) transparent images (replacing PNG), (2) hero and LCP images, (3) the large volume of photos, and (4) moving illustrations and screenshots that are already WebP to AVIF.

Testing With Your Own Images - Squoosh, cwebp, avifenc

Because the difference between formats depends on the image and the settings, the reliable approach is to pick a few images you actually serve on your site and test them before adopting a format. Below are two ways to do this, easiest first, followed by a principle for comparing the results fairly.

In the browser (Squoosh): Squoosh (squoosh.app) compresses images in the browser and lets you compare the result against the original while changing the codec and quality. The file size is shown as you go, which makes it well suited to finding the lowest quality that still looks acceptable. No installation is required.

On the command line (cwebp / avifenc): cwebp, which ships with libwebp, takes a quality from 0 to 100 via -q (default 75; cwebp documentation, updated August 2025) and switches to lossless mode with -lossless. avifenc, which ships with libavif, also accepts a quality via -q (libavif README). Export the same image at several quality levels and tabulate size against appearance, and the right settings for your images become clear.

cwebp -q 75 input.png -o output.webp
avifenc -q 75 input.png output.avif

Comparing at matched quality: For a fair comparison, decide either to match file size and compare appearance, or to match appearance and compare size. Quality metrics such as SSIM are one option, but in the end a visual check at the actual display size is the reliable one. Text, skin, sky gradients, and fine texture are the four areas where degradation shows first, so inspect them closely.

The numbers you get at this stage apply only to your images and your settings. It is no surprise if they disagree with comparison figures published elsewhere; basing decisions on your own measurements is the safe course.

Summary - A Decision Path When in Doubt

Finally, here is the decision path in order.

• If compatibility comes first and you want minimal effort, keep JPEG (photos) and PNG (transparency, text) and simply revisit the quality settings.
• If you want a large reduction with simple operations, move to WebP and keep JPEG / PNG as fallbacks in a picture element.
• If you want to go further, or need HDR or high bit depth, make AVIF the first choice with a three-tier fallback to WebP and JPEG, and absorb the longer encoding time in batch processing at build time.
• For animation, use animated WebP by default and substitute a video element for longer clips.

At every stage, the keys to a smooth migration are to verify quality and size with your own images before adopting a format, and to keep older environments working through picture fallbacks. Format support and encoders are still evolving, so check caniuse and the official documentation for updates from time to time.