What makes WebP and AVIF smaller than JPEG?
JPEG dates from the early 1990s. It splits a photo into small blocks and stores each block in a way that throws away detail the eye is less likely to miss. It works everywhere and it is still a reasonable format, but encoders have learned a lot since.
WebP and AVIF use newer methods from video compression. They predict each part of the picture from the parts around it and store only the difference, and they can use larger and more flexible blocks. For the same visible quality, WebP is often around a quarter to a third smaller than JPEG, and AVIF often half the size or less.
On the bakery photo, the same 800 by 533 picture is 120 KB as JPEG, 78 KB as WebP and 52 KB as AVIF. The pixel size is the same in all three. Only the way the pixels are packed has changed.
Which browsers can show them?
WebP works in every current major browser, and has for years. AVIF works in current Chrome, Edge, Firefox and Safari; Safari added it in 2022 and completed support in version 16.4 in 2023. A small share of visitors still use older phones or browsers that can't show AVIF, and some apps that open links in their own viewers lag behind.
That share is small but real, and an image that fails to show at all is far worse than a slightly heavier one. That is why the usual pattern offers the new formats and keeps a JPEG as the fallback. Every browser gets a photo, and most get the lightest one.
How does `<picture>` choose a file?
A <picture> element holds any number of <source> elements and then one <img>. The browser reads the sources in order. For each one, it checks the type and, if present, the media condition. It uses the first source it can handle and ignores the rest.
If no source fits, it uses the <img> itself. The <img> is also what actually gets drawn, so it keeps the alt text, the width and height, any loading or fetchpriority attribute and the class for styling. The sources only change which file goes into it.
<picture>
<source srcset="/img/loaves.avif" type="image/avif">
<source srcset="/img/loaves.webp" type="image/webp">
<img src="/img/loaves.jpg" alt="Sourdough loaves on a wooden board"
width="800" height="533">
</picture>
Why does the order of the sources matter?
The browser stops at the first match. A browser that supports both formats and finds the WebP source first will take WebP, even though the AVIF below it is smaller. That is exactly what happens on the cinnamon bun page in Break It: the phone downloads 76 KB when a 50 KB copy was right there.
List the sources from smallest file to largest, which in practice means AVIF, then WebP, then the JPEG in the <img>. Each browser then gets the lightest format it understands.
The type attribute does the work. Without it, the browser assumes it can show the file and takes that source whatever the format, which defeats the fallback. Always write the full media type: image/avif, image/webp.
Does the browser download every format?
No. It makes its choice before it requests anything, and downloads only the file it picked. Watch the Waterfall after your change: the JPEG row disappears, no WebP row takes its place, and only loaves.avif is fetched. Offering three formats costs nothing extra on the network; it only costs storage on your server, plus the time to export each photo three times. A build step or image service can do that for you whenever a new photo is added.
There is one catch. Once a browser has picked a source, it sticks with it. If that file is missing, it shows a broken image and does not try the next source or the <img> fallback. The rye.avf typo in Break It leaves a blank space for exactly that reason, so check every path.
Is AVIF always the right choice?
For photos, it usually wins on size. It is slower to encode, which slows you down when you convert thousands of images on your own machine, and some image editors still lack good export options for it. Very small images and some flat graphics can come out larger as AVIF than WebP, so compare the sizes your tools report.
For logos, icons and diagrams, SVG is often better than any of these formats. For screenshots with sharp text, lossless WebP or PNG may look cleaner. The new formats are mainly a photo decision.
Format and pixel size work together. A 2,400 pixel AVIF is still far heavier than an 800 pixel one. Get the size right first, as in the previous lesson, then pick the format.
How do you check which format a browser chose?
In Chrome DevTools, open the Network panel and filter to Img. The Type column shows avif, webp or jpeg for each request, and the Size column shows its cost. Hover the <img> inside the <picture> in the Elements panel to see the current source URL.
To test the fallback, you need a browser that lacks the format. Chrome's Rendering panel has options to disable AVIF and WebP for the current tab, which lets you watch the next source or the JPEG take over. Lighthouse also reports images that could be served in a newer format, with an estimate of the saving.
What do AI tools get wrong about image formats?
AI-written <picture> markup often lists WebP before AVIF, leaves out the type attribute, or moves the alt, width and height onto a <source>, where they do nothing. Some answers drop the <img> altogether, which leaves nothing to draw.
AI advice also tends to say "convert to WebP" and stop. Check the result: the saving depends on the photo and the quality setting, and an image that is still three times too wide gains less from a new format than from resizing. Measure the KB in the Waterfall before and after each change.
Field notes
- WebP and AVIF usually store the same photo in fewer bytes than JPEG.
- A
<picture>element lists sources, and the browser takes the first one it supports. - Put AVIF before WebP, because the browser stops at the first match.
- Keep a JPEG
<img>inside as the fallback; it also holdsalt,widthandheight.
Easy to get wrong
The browser takes the first source it supports. Put the smallest format first, or browsers that support both will take the heavier file.
Without type, a browser that can't show AVIF still picks that source and shows a broken image.
The <img> is what gets drawn and read by screen readers. Keep alt, width and height on it.
Questions people ask
Can I serve WebP without `<picture>`?
Yes, if every browser you care about supports it, which for WebP is nearly all of them. A plain <img src="/img/loaves.webp"> works. You need <picture> when you want AVIF and a safe fallback.
Can the server choose the format instead?
Yes. Browsers send an Accept header listing image types they support, and a server or image service can pick the format from it while the URL stays the same. That keeps the HTML simple, but the server must also send Vary: Accept so caches don't mix formats up.
Does the simulator know which formats a phone supports?
It treats its phone as a current browser that supports AVIF, WebP, JPEG, PNG and SVG, and like a real browser it takes the first matching source. It never tests the fallback path, which you would check in DevTools.
What about JPEG XL?
JPEG XL compresses well, and Safari can show it, but as of 2026 it is not supported widely enough to rely on without a fallback. If you add it, list it in its own <source> with type="image/jxl" and keep the other formats.