Stop Using JPG and PNG: Why Modern Web Apps Use WebP and AVIF

The Image Problem Nobody Talks About

When you load a webpage, images are almost always the heaviest assets on the page. Not your JavaScript bundles. Not your fonts. Images.

A single unoptimized product photo can easily weigh 2–4 MB in JPEG or PNG. Multiply that by a gallery of twelve items and you are shipping 30–50 MB of image data to every visitor — before a single line of your app logic even runs.

This matters because slow pages lose users. Research consistently shows that even a one-second delay in page load time reduces conversions significantly. More concretely, image size directly affects your Largest Contentful Paint (LCP) score — one of Google’s Core Web Vitals that influences search ranking.

The solution is not to use fewer images. The solution is to use the right format.

The Legacy Formats: Where JPG and PNG Fall Short

Before diving into modern formats, it helps to understand why the old ones exist and where they break down.

JPEG (1992) JPEG uses lossy compression, meaning it discards some image data to reduce file size. It works well for photographs and complex scenes but struggles with sharp edges, text, and transparency. It also has no transparency support at all.

PNG (1996) PNG uses lossless compression — no data is discarded, so it is perfect for logos, icons, and screenshots with sharp edges. It also supports transparency. The trade-off: file sizes are significantly larger than JPEG for the same visual content.

GIF (1987) GIF supports animation and transparency, but is limited to 256 colors. It produces enormous files for anything beyond simple pixel art animations.

These formats were designed in a completely different era of the web. Bandwidth was expensive, screens were small, and the concept of a responsive image pipeline did not exist. We have kept using them out of habit, not necessity.

Enter WebP

Google introduced WebP in 2010 and it has seen near-universal browser support since around 2020. It was built specifically to replace JPEG and PNG on the web.

What Makes WebP Better

WebP supports both lossy and lossless compression, meaning you get one format that can handle photographs and graphics alike. It also supports transparency (alpha channel) — something JPEG could never do.

The compression gains are substantial:

A 500 KB JPEG photograph will typically come in at around 300–350 KB as WebP at equivalent visual quality. For a site with hundreds of images, that reduction compounds into meaningful bandwidth savings.

Browser Support

As of 2026, WebP is supported across all modern browsers including Chrome, Firefox, Safari (since version 14), Edge, and Opera. The only scenario where you need a fallback is legacy Internet Explorer, which is effectively irrelevant at this point.

AVIF: The Next Step

AVIF (AV1 Image File Format) is newer, derived from the AV1 video codec developed by the Alliance for Open Media — a coalition that includes Google, Apple, Microsoft, and Netflix. It was designed to push image compression further than WebP.

Why AVIF Compresses So Well

AV1 was originally a video codec built for streaming high-quality video at low bitrates. Applying that same compression algorithm to still images produces results that are difficult to match with older codecs.

The numbers speak for themselves:

A photograph that is 500 KB in JPEG may come out at 200–280 KB in AVIF at equivalent quality — sometimes smaller, depending on the content. AVIF also has a wider color gamut, HDR support, and better handling of smooth gradients.

Browser Support

AVIF support arrived more recently than WebP:

• Chrome: supported since version 85 (2020)
• Firefox: supported since version 93 (2021)
• Safari: supported since version 16 (2022)
• Edge: supported since version 121 (2024)

Browser support is solid for the majority of users but not yet at the near-universal level WebP enjoys. This is exactly why you serve both.

How to Use Them: The <picture> Element

The browser-native way to serve modern formats with automatic fallback is the <picture> element. You list sources in order of preference, and the browser picks the first one it supports.

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero image" width="1200" height="630" />
</picture>

What happens here:

1. A browser that supports AVIF loads hero.avif — the smallest file.
2. A browser that supports WebP but not AVIF loads hero.webp — still significantly smaller than JPEG.
3. A very old browser that supports neither falls back to hero.jpg.

The <img> tag at the bottom is not just a fallback — it is required. It also carries the alt, width, and height attributes, which matter for accessibility and layout stability (preventing Cumulative Layout Shift).

Combining Format with Responsive Sizes

Format optimization and responsive sizing work together. There is no point serving a 1600 px wide image to a phone with a 390 px screen.

<picture>
  <source
    type="image/avif"
    srcset="
      hero-400.avif   400w,
      hero-800.avif   800w,
      hero-1200.avif 1200w
    "
    sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px"
  />
  <source
    type="image/webp"
    srcset="
      hero-400.webp   400w,
      hero-800.webp   800w,
      hero-1200.webp 1200w
    "
    sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1200px"
  />
  <img
    src="hero-1200.jpg"
    alt="Hero image"
    width="1200"
    height="630"
    loading="lazy"
  />
</picture>

The browser now picks both the right format and the right resolution for the device. A mobile user on a slow connection gets a small AVIF. A desktop user gets a large AVIF. An older browser gets an appropriately sized JPEG.

Converting Images: Practical Tools

You do not need to re-export everything manually. These tools handle conversion at scale.

CLI tools (local)

# cwebp — Google's official WebP encoder
cwebp -q 80 input.jpg -o output.webp

# sharp — Node.js image processing
npx sharp input.jpg -o output.avif

# ImageMagick
convert input.jpg -quality 80 output.webp

Build pipeline integration

If you use Vite, the vite-imagetools plugin converts images at build time:

// vite.config.js
import { imagetools } from 'vite-imagetools'

export default {
  plugins: [imagetools()]
}

Then reference the image in your component with format params:

<img src="./hero.jpg?format=avif&w=800" />

CDN-level conversion

Services like Cloudinary, Imgix, and AWS CloudFront with Lambda@Edge can convert images on the fly using the Accept header the browser sends. You store one original and the CDN serves the right format automatically — no build pipeline changes required.

# Cloudinary auto-format example
https://res.cloudinary.com/your-cloud/image/upload/f_auto,q_auto/hero.jpg

The f_auto parameter tells Cloudinary to detect browser support and serve AVIF, WebP, or JPEG accordingly.

The Performance Impact

To make this concrete, here is what format optimization typically produces on a real project:

• Total page weight: Reduced by 30–60% for image-heavy pages.
• LCP (Largest Contentful Paint): Often the single biggest lever for improvement on content-heavy pages. Getting LCP under 2.5 seconds frequently comes down to image optimization first.
• Bandwidth costs: If you host on AWS S3 and CloudFront, smaller images mean lower data transfer fees at scale.
• Mobile experience: On a 4G or 3G connection, the difference between a 2 MB JPEG and a 700 KB AVIF is measured in seconds, not milliseconds.

A Note on Quality Settings

Compression comes with a quality dial. The key is finding the point where the file is small but the image still looks good to the human eye.

Common starting points:

Always do a side-by-side comparison before shipping. Some images — particularly those with fine detail or sharp text overlays — need a higher quality setting to avoid visible artifacts.

Summary

The move from JPEG and PNG to WebP and AVIF is one of the highest-return optimizations available in web development. It requires no change to your application logic, no new runtime dependencies, and the browser handles format selection automatically through the <picture> element.

The rule of thumb is straightforward:

• Serve AVIF as the primary format where supported.
• Serve WebP as the fallback.
• Keep JPEG or PNG only as the final fallback for legacy browsers or tooling constraints.

If you are building for the web today and still defaulting to JPEG and PNG everywhere, you are leaving performance on the table. The formats that replaced them have been stable and widely supported for years. There is no reason to wait.