Next-Gen Image Formats

## Why it matters

A 300 KB PNG photograph of a product would be 60 KB as AVIF. That's five times smaller, transferred five times faster, and displayed identically on screen. Multiply that across 50 images on a page and you're saving 12 MB of bandwidth per visitor. That's the performance win that's kept the loudest.

But next-gen isn't magic: WebP and AVIF are only worth it if you can actually serve them to the browser. Older browsers (Internet Explorer, Safari on iOS below version 16) don't understand them. That's where the <picture> element comes in: you offer WebP or AVIF as the first choice, then fall back to JPEG for browsers that don't support it. The user always gets something that works, and modern browsers get the smaller file.

The first step is knowing which images on your site are still JPEG, PNG, or GIF. Scalpel Images flags those as conversion candidates.

## How it works

WebP: Released by Google in 2010, WebP combines the best of JPEG and PNG. Lossy mode (like JPEG) compresses photographs by about 25–35% smaller than JPEG at the same quality. Lossless mode (like PNG) compresses flat graphics by 25–30% smaller than PNG. It also supports animation and transparency, so it can replace GIF and animated PNG.

Browser support is now broad: Chrome, Edge, Firefox (91+), Safari (14+), Opera, and most mobile browsers. Only Internet Explorer and very old Safari versions fail. Using <picture> with a JPEG fallback bridges that gap.

AVIF: Newer and more aggressive, released around 2019. It compresses up to 50% better than WebP in many cases, especially on photographs and images with complex colour gradients. The catch: encoding is slower (AVIF takes longer to generate), and browser support is still catching up. Chrome 85+, Firefox 93+, Safari 16.1+ on desktop, and Safari 16.4+ on iOS support it. Internet Explorer and older browsers need a fallback.

Which wins? For most jobs: use WebP as your primary modern format, with JPEG as the fallback for older browsers. Add AVIF as a second choice if you have the build time and bandwidth savings matter. That looks like this in HTML:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Product photo">
</picture>
Copy

The browser walks the list top-to-bottom and stops at the first format it understands.

Flat graphics, icons and logos: SVG usually wins here. It scales to any size with no quality loss, and modern SVGs are often smaller than WebP or AVIF. If you're using raster formats for simple graphics, PNG or WebP lossless is the choice.

Animated: WebP and AVIF both support animation. WebP animated is well-supported. AVIF animated is newer and less broadly supported. Check your analytics. GIF is almost never the best choice anymore; it's huge and has only 256 colours. Upgrade to WebP animated or AVIF animated if you can.

## What does not matter

Don't re-encode everything just because next-gen formats exist. Conversion belongs in your build process, not in a downloader. An image that's already WebP doesn't need to become AVIF. The win scales with file size: converting a bloated 500 KB PNG is worth it; converting a careful 35 KB PNG? Probably not. Scalpel flags only JPEG, PNG and GIF as candidates, not images already in WebP or AVIF.

Don't worry about perceived quality loss. If you run your encoder at the right quality setting (usually 80–85 for lossy), the human eye won't see a difference between the original and the WebP or AVIF version. Most quality complaints come from encoders set too aggressively.

Perfect browser support isn't required. The 2–3% of traffic from ancient browsers isn't worth delaying a performance win. Use <picture> with a sensible fallback and move on. Your analytics engine can tell you if your actual users are hitting the fallback often; most real traffic supports the modern formats.

## Code example

Here's a basic HTML <picture> pattern that's safe for production:

<!-- AVIF for cutting-edge browsers, WebP for modern ones, JPEG for everyone else -->
<picture>
  <source
    srcset="/images/photo-large.avif 1200w, /images/photo-small.avif 400w"
    type="image/avif"
    media="(min-width: 768px)"
  >
  <source
    srcset="/images/photo-small.avif"
    type="image/avif"
  >
  <source
    srcset="/images/photo-large.webp 1200w, /images/photo-small.webp 400w"
    type="image/webp"
    media="(min-width: 768px)"
  >
  <source
    srcset="/images/photo-small.webp"
    type="image/webp"
  >
  <img
    src="/images/photo-small.jpg"
    alt="Product shot"
    width="400"
    height="300"
  >
</picture>
Copy

And a minimal CSS approach using image-set():

.hero {
  background-image: image-set(
    url(/hero.avif) type('image/avif'),
    url(/hero.webp) type('image/webp'),
    url(/hero.jpg) type('image/jpeg')
  );
  background-size: cover;
}
Copy

For bulk conversion from the command line, tools like ImageMagick or the cwebp encoder handle WebP:

# WebP (fast, safe)
cwebp -q 80 photo.jpg -o photo.webp

# AVIF (slower, more compression)
ffmpeg -i photo.jpg -c:v libaom-av1 -crf 30 photo.avif
Copy

## How Scalpel shows it

The advice chip in the Scalpel Images filter bar counts how many images on the page could convert: "25 JPEG/PNG images could be smaller as WebP or AVIF." Click it and a →WEBP or →AVIF badge appears on each eligible tile, so you can see which ones matter most. The recommendation is advisory only: Scalpel doesn't re-encode anything, because conversion belongs in your build pipeline, not in a downloader.

Sort by weight and the heaviest JPEGs bubble to the top. Those are your best targets for conversion. Often the top three converted images will pay for the time to set up WebP or AVIF in your build.