For most websites in 2026, the answer is layered: serve AVIF for the biggest savings (often around 50% smaller than JPEG at similar quality), fall back to WebP for near-universal support, and keep JPEG for the oldest clients. AVIF wins on file size, WebP wins on compatibility, JPEG wins on being everywhere.
If you have been hand-wringing over which next-gen image format to commit to, here is the freeing part: you do not have to pick just one. The modern approach serves all three and lets each browser take the smallest version it can decode. This guide gives you the decision rule, the real size and support trade-offs, and how each format hits Core Web Vitals, so you can stop guessing and ship.
WebP vs AVIF vs JPEG: The Quick Answer#
The three formats sit on a clear spectrum of newer-and-smaller versus older-and-safer:
- JPEG (1992) is the universal baseline. Every browser, OS, and device opens it. It is also the least efficient, so identical quality costs the most bytes.
- WebP (Google, 2010) typically runs 25% to 35% smaller than JPEG at comparable quality, and it is now supported by essentially every browser in use. This is your safe default.
- AVIF (2019, based on the AV1 video codec) is the most efficient of the three, frequently around 50% smaller than JPEG and noticeably smaller than WebP, with support across all current major browsers.
The decision in one line: use AVIF as the primary format with WebP as the fallback, and only keep JPEG around if you must support very old clients. Serve them together with the HTML <picture> element so the browser picks the best one it understands.
How the Three Formats Compare#
The trade-offs come down to four things: file size, browser support, features, and encoding cost. Here is the side-by-side.
| Format | Typical size vs JPEG | Browser support | Transparency | Best for |
|---|---|---|---|---|
| JPEG | Baseline (100%) | Universal, every browser ever | No | Photos, fallback, email |
| WebP | ~25-35% smaller | All current browsers | Yes (lossy + lossless) | Safe universal default |
| AVIF | ~50% smaller | All current major browsers | Yes, plus HDR/wide gamut | Hero images, max savings |
A few details behind the table:
- Size figures are approximate and depend on the image. Photographic content with smooth gradients (skies, skin) is where AVIF pulls furthest ahead. Simple graphics with flat color see smaller gains, and there a well-optimized PNG or SVG may still win.
- Encoding speed: AVIF is slower to encode than WebP or JPEG, which matters for build pipelines compressing thousands of images, but is irrelevant for a one-off upload.
- Transparency: both WebP and AVIF support alpha transparency, so they can replace PNG for photographic images with transparent backgrounds, often at a fraction of the size.
A practical note on quality: do not chase the absolute smallest file. At very aggressive AVIF settings you can introduce smudgy, "watercolor" artifacts in fine detail. Aim for the smallest file that still looks clean at full size, not the smallest file full stop.
Why File Size Decides Core Web Vitals#
This is the part that connects format choice to rankings and revenue. Images are usually the heaviest thing on a page, and the largest image is very often the Largest Contentful Paint (LCP) element, the hero shot or featured image that defines when Google considers your page "loaded."
LCP is one of Google's Core Web Vitals, and a slow one hurts both user experience and search performance. The math is direct: if your hero image is a 400 KB JPEG and the AVIF version is 200 KB, you have halved the bytes the browser must download before LCP fires. On a mobile connection, that can be the difference between a "good" and a "needs improvement" score.
Two more size-driven wins worth naming:
- Bandwidth and cost: smaller images mean less data transferred, which lowers CDN bills and helps users on metered or slow connections.
- Crawl efficiency: lighter pages render faster for everyone, including the rendering step search engines perform.
The takeaway is that "best image format for the web" is really a Core Web Vitals question. Smaller, correctly-served images are one of the highest-leverage page-speed fixes you can make.
How to Serve All Three With One Tag#
You do not choose a single format for your whole site. You provide the modern formats and a fallback, and the browser selects the first one it can decode. The <picture> element handles this natively.
Step 1: Compress your source image to all three formats#
Start from your highest-quality original (the raw JPEG or PNG straight from the camera or design tool). Export an AVIF, a WebP, and an optimized JPEG of the same image at the same dimensions. A free image compressor does this in one pass and runs entirely in your browser, so the original photo never uploads to a server.
Step 2: Wire them into a picture element#
List the formats from smallest to largest. The browser reads top to bottom and stops at the first type it supports, so AVIF goes first, WebP second, and the plain <img> JPEG is the universal fallback.
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Descriptive alt text" width="1200" height="630">
</picture>
Keep the width and height attributes on the <img>. They let the browser reserve space before the image loads, which prevents layout shift (CLS, another Core Web Vital).
Step 3: Strip metadata and right-size before you compress#
Two cheap wins before you ever pick a format. First, resize to the actual display dimensions. Serving a 4000px photo into a 1200px slot wastes bytes no codec can recover, so use an image resizer to match the real layout size. Second, strip EXIF metadata (camera model, GPS coordinates, timestamps), which adds weight and can leak private location data. Good compressors remove it automatically.
Step 4: Let the tool auto-pick the smallest#
Rather than eyeballing three exports, compress to all three formats and compare the output sizes directly. The free image compressor shows the resulting byte size for each format from a single upload, so you can drop in the smallest that still looks clean, without manual trial and error.
Lossy vs Lossless, and Choosing a Quality Level#
All three formats are usually used in lossy mode for photos, meaning they discard detail the eye barely notices in exchange for dramatically smaller files. WebP and AVIF also support lossless mode, which keeps every pixel but produces larger files, useful for screenshots, diagrams, or images with crisp text and flat color.
The quality setting is where most of the savings (and most of the mistakes) happen:
- JPEG quality 75-85 is the sweet spot for photos. Below ~70 you start seeing blocky artifacts around edges.
- WebP quality 75-80 roughly matches JPEG 85 at a smaller size, because WebP compresses more efficiently at the same perceived quality.
- AVIF quality 50-65 often looks as clean as a much higher JPEG setting. AVIF's quality scale is not directly comparable to JPEG's, so do not assume "quality 80" means the same thing across formats.
The reliable method is not to trust a number but to compare output. Encode the image, view it at full display size, and step the quality down until you see the first artifact, then back off one notch. That gives you the smallest acceptable file for that specific image, which is always better than a blanket quality setting applied to everything.
One subtle trap: re-compressing an already-lossy image (taking a JPEG and saving it as a lossy WebP) compounds the loss. Always export your modern formats from the highest-quality original you have, not from a previously compressed copy.
Responsive Images: Serving the Right Size, Not Just the Right Format#
Format is half the page-speed equation. The other half is dimensions. A phone with a 400px-wide screen has no use for a 1600px image, and shipping the big one wastes bytes regardless of format.
The srcset and sizes attributes let you offer several sizes of the same image and let the browser pick based on the device's screen and resolution. You can combine this with <picture> so each format also comes in multiple widths.
<picture>
<source
type="image/avif"
srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
sizes="(max-width: 600px) 400px, 1200px">
<img src="hero-800.jpg" alt="Descriptive alt text" width="1200" height="630">
</picture>
This pairs the format win (AVIF over JPEG) with the size win (a 400px image to phones), and the two savings stack. For a content site where the same article runs on phones and desktops, this combination is often the single biggest mobile LCP improvement available.
If hand-writing this markup is too much, most modern frameworks and CMS platforms generate AVIF and WebP variants and the responsive markup automatically on upload. The principle is the same either way: smallest format the browser supports, at the smallest size the layout needs.
When NOT to Use AVIF or WebP#
These formats are for photographs and complex raster images. They are the wrong tool for two common cases:
- Logos, icons, and line art: use SVG. It is a vector format, so it stays razor-sharp at any size and is usually tiny. If you only have a raster logo, our guide and tool for converting SVG to PNG covers the round trip.
- Animations: short loops are far better served as a muted, autoplaying video (MP4 or WebM) than as a heavy animated GIF or even animated WebP.
There is also the edge case of a few very old or niche clients that decode neither AVIF nor WebP. That is exactly what the JPEG fallback in your <picture> element is for, so you lose nothing by including it.
The 2026 Decision Rule, Summarized#
Put it all together and the workflow is short:
- Default to AVIF, fall back to WebP, keep JPEG as the safety net. Serve all three with
<picture>and let the browser choose. - AVIF for hero and large photos, where its ~50% saving over JPEG does the most for LCP.
- WebP if you serve only one modern format, because its support is effectively universal and it still beats JPEG comfortably.
- SVG for logos and icons, never a raster format.
- Resize first, strip metadata, then compress, and let the tool report which format came out smallest.
Format choice is just one lever. For the full picture on shrinking page weight without wrecking quality, see our walkthrough on using a free image compressor to boost page speed.
Frequently Asked Questions#
Is AVIF better than WebP? For file size, usually yes. AVIF typically produces smaller files than WebP at similar quality, often noticeably so on photographic images, and it adds HDR and wide-gamut support. WebP encodes faster and has had universal support slightly longer, which is why the common pattern is AVIF first with WebP as the fallback.
How much smaller is AVIF than JPEG? On typical photographic content, AVIF is often around 50% smaller than JPEG at comparable visual quality, though the exact saving depends on the image. Photos with smooth gradients see the biggest gains, while flat-color graphics see less, where SVG or PNG may be the better choice anyway.
Should I just use WebP for everything? WebP is a strong, safe default because its browser support is essentially universal and it beats JPEG on size. But serving AVIF as the primary format with WebP as the fallback gets you smaller files still, at no compatibility cost, since the browser only takes AVIF if it can decode it.
Do these formats hurt SEO? The opposite. Smaller images speed up Largest Contentful Paint, a Core Web Vital that affects both user experience and search performance. Just keep descriptive alt text and correct width and height attributes so you also avoid layout shift.
How do I convert a JPEG to WebP or AVIF for free? Upload your image to a free browser-based image compressor, which exports WebP and AVIF without sending the file to a server. Compress to all three formats at once and keep whichever comes out smallest while still looking clean at full size.
What is the smallest image file format for the web? For photographs, AVIF is generally the smallest of the common raster formats, ahead of WebP and well ahead of JPEG. For logos, icons, and line art, SVG is smaller still because it is vector-based and scales without adding pixels.
