Modern image formats
AVIF, WebP, JPEG XL, and the old guard — what each format wins on, and how to ship them without breaking older browsers.
A photograph saved as a JPEG and an AVIF can be 30 to 50 percent different in file size — for the same visible quality. That difference is bandwidth a user does not pay for, page-load milliseconds you do not spend, and CDN bills you do not pay.
This lesson covers the formats that matter in 2026, what each is best at, and how to combine them so users on every browser get the most efficient version their browser can decode.
JPEG, PNG, GIF
The three formats every browser has supported since the 1990s. Each has a niche.
JPEG — for photos and complex imagery with smooth color gradients. Lossy compression — the file gets smaller by throwing away detail the human eye is least likely to notice. No transparency. No animation.
PNG — for images with sharp edges (logos, screenshots, UI elements) and for transparency. Lossless compression — the file is exact, no quality loss, but bigger than JPEG for photos. PNG-8 is small (256 colors); PNG-24/32 holds millions plus alpha.
GIF — for short, looping animations. Limited to 256 colors per frame, which makes for grainy results on anything photographic. Functionally obsolete; an <img src="loop.webp"> or a tiny <video autoplay loop muted playsinline> beats it on every axis. Still common in the wild.
The 2026 reality: you ship JPEG and PNG only as the fallback in a <picture> chain. The bytes you actually serve to most users come from the modern formats below.
WebP
Google's format, supported in every evergreen browser since 2020. Two key wins:
- About 25-35% smaller files than JPEG for photographic content at equivalent quality.
- Supports both lossless and lossy compression, plus transparency, plus animation. One format does the job of JPEG, PNG, and GIF.
WebP's quality knob feels a lot like JPEG's. A WebP at quality 80 is roughly equivalent to a JPEG at quality 85. Build pipelines (sharp, ImageMagick, cwebp) convert in one command.
<picture> <source srcset="loaf.webp" type="image/webp"> <img src="loaf.jpg" alt="..." width="800" height="600"> </picture>
The pattern: serve WebP to browsers that support it, JPEG to anything else. The fallback <img> is your safety net.
WebP is the minimum modern format in 2026 — there is no good reason not to ship it.
AVIF
A newer format, derived from the AV1 video codec, supported in every evergreen browser since late 2023. Two key wins:
- About 30-50% smaller than JPEG, often 20% smaller than WebP for photographic content.
- Better quality at low bitrates — small AVIFs look noticeably less mushy than equivalently-small WebPs. Helpful for thumbnails and below-fold images.
The trade-off: AVIF is slower to encode. A WebP build might take 100ms per image; an AVIF can take 1-3 seconds. Build pipelines that re-encode every image on every commit feel the slowdown. CDNs that re-encode on demand absorb it for you.
<picture> <source srcset="loaf.avif" type="image/avif"> <source srcset="loaf.webp" type="image/webp"> <img src="loaf.jpg" alt="..." width="800" height="600"> </picture>
The pattern: AVIF first, WebP next, JPEG last. Browsers that decode AVIF take it; older browsers fall through to WebP; the rest get JPEG.
AVIF's encoder is good at quality but slow. If you are pre-building images at deploy time, set up a parallel encoding step or use a service that does it on demand. Re-encoding every image on every commit is the failure mode that scares teams off AVIF.
hero.avif (180 KB), hero.webp (240 KB), and hero.jpg (320 KB) inside a <picture>. A user on the latest Chrome loads the page. What gets downloaded?JPEG XL, the dark horse
A newer format that promises better-than-AVIF compression with faster encoding and a path to losslessly transcode existing JPEGs. The catch: browser support has been complicated. Safari shipped support; Chrome wavered for a long time, then re-added it as a feature flag, then began shipping it more broadly through 2025 and 2026.
By the time you read this, JPEG XL may be widely supported, partially supported, or in flux again. The pattern when adding it is the same as for AVIF: a <source type="image/jxl"> at the top of the chain, with AVIF and WebP behind it as fallbacks.
For most production sites today, AVIF + WebP + JPEG covers 99%+ of users. JPEG XL is worth tracking but does not need to be in your pipeline unless your audience skews heavily Safari.
Picking a format
A short decision tree.
Photos and photographic content (people, scenery, product shots): AVIF first, WebP second, JPEG fallback. The savings are biggest here.
Logos, icons, simple UI imagery (sharp edges, flat colors, transparency): SVG when possible (lesson 7). When raster, AVIF lossless or PNG fallback.
Animated content: a tiny <video autoplay loop muted playsinline> with H.264 or AV1 source beats animated GIF on every axis. If the animation is short and decorative, animated WebP works too.
Charts, diagrams, screenshots: SVG if you have it; PNG if not. AVIF lossless can win here too.
The rule of thumb: if a chunk of your page is photographic, AVIF is worth the build pipeline. If it is geometric (logos, icons, diagrams), SVG is almost always the right answer.
Don't ship the same photo as a JPEG and as PNG hoping the browser picks the better one. The browser does not compare file sizes; it picks the first source it can decode (within a <picture>) or the only file (in <img>). You decide the order; you bear the cost of choosing the wrong one.
A useful picture: image formats are a stack of menu options at a restaurant. The browser walks the menu top-to-bottom and picks the first dish it can eat. Your job is to put the smallest, freshest dish at the top.