SVG vs PNG vs WebP vs AVIF — Which Image Format?
Photo by Unsplash on Unsplash
Table of Contents
Pick by Asset Type First
I've spent more time than I'd like to admit arguing about image formats, and the thing that finally made it click was realizing it's two decisions, not one. First: is this a drawing or a photo? Second: which raster format and fallback do I serve? Get the first one right and the second one mostly follows.
This guide goes format by format — what each is good at, the file-size reality, and the fallback pattern I use on real sites. By the end you'll be able to look at any asset and know exactly what to export.
SVG — The Vector One
Use SVG for logos, icons, simple illustrations, and anything geometric. The wins are dramatic: an SVG logo is often 1-3KB total, versus 25-50KB for a PNG equivalent (plus another 100-200KB if you ship a @2x retina version). And because it's vector, it scales infinitely — the same file looks crisp on a phone and on a 5K monitor with zero extra bytes.
The other superpower is that SVG lives in the DOM. You can style it with CSS, change its color with `fill`, animate it, and even make it accessible with proper `<title>` and ARIA attributes. Try doing any of that with a PNG icon — you can't.
What SVG is bad at: photographs. A photo has thousands of subtly varying pixels, and describing that as vector paths would produce a massive, slow file. Never export a photo as SVG. Also be careful with SVGs from untrusted sources, since they can contain scripts — sanitize user-uploaded SVGs.
One pattern worth knowing: for tiny inline icons, you can drop the SVG markup directly into your HTML or even inline it as a data URI. I covered the tradeoffs of inlining in data URIs vs external images — for small, frequently-used icons, inlining can save a round trip.
There's one more thing about SVG that trips people up: file size isn't fixed by dimensions, it's driven by complexity. A simple two-color logo stays tiny no matter how big you display it, but a detailed illustration with hundreds of paths, gradients, and filters can balloon into something heavier than the equivalent PNG. So "SVG is always smaller" is wrong — SVG is smaller *for simple geometric art*. For an intricate illustration, test both and measure. And always run SVGs through an optimizer like SVGO before shipping; design tools export a lot of metadata, editor cruft, and redundant precision that an optimizer strips out, often cutting the file by half with no visual change. I treat that as a non-negotiable build step for any SVG, the same way I'd never ship an un-minified JS bundle.
PNG and JPEG — The Old Reliables
Photo by Unsplash on Unsplash
JPEG is lossy and built for photographs. It throws away detail your eye won't miss to get small files, which works great for complex, colorful images where perfect edges don't matter. The downside: it has no transparency, and aggressive compression produces visible artifacts around sharp edges and text. JPEG remains the safe universal-compatibility choice — email, documents, anywhere you can't guarantee modern format support.
PNG is lossless and supports transparency (including a full alpha channel). Use it for screenshots, graphics with sharp text, diagrams, and anything where you need pixel-perfect quality or a transparent background without artifacts. The cost is file size — PNG files are big because they preserve everything. A photo saved as PNG is wastefully large; that's JPEG's (or WebP's) job.
The simple mental model: photo where size matters → JPEG; lossless graphic or transparency → PNG. But in practice, you'll usually serve the WebP or AVIF version of both and keep these as the bottom of the fallback stack. Knowing when each format's strengths apply is half the battle; the other half is delivering them efficiently, which is where the `<picture>` element comes in below.
One lingering myth I'll kill: PNG-8 versus PNG-24. PNG-8 uses a 256-color palette like GIF and can be tiny, while PNG-24 is full-color and bigger. For flat graphics with few colors, PNG-8 is dramatically smaller than PNG-24 and most people never realize their export tool defaulted to the heavy one. That said, in 2026 I'd usually just reach for lossless WebP instead and skip the PNG-8/PNG-24 decision entirely — it's smaller than both and keeps transparency. The old format choices still matter when you're stuck supporting ancient clients, but for the modern web they're mostly a fallback footnote.
WebP and AVIF — The Modern Defaults
WebP is the best all-purpose modern format. It does both lossy (like JPEG) and lossless (like PNG) compression, supports transparency and animation, and runs about 25-35% smaller than JPEG at equivalent quality. Browser support is around 96% globally — every modern Chrome, Firefox, Safari 14+, and Edge handles it natively. For most photos and graphics, WebP is the sweet spot of size, quality, and compatibility.
AVIF goes further. Built on the AV1 video codec, it compresses roughly 50% smaller than JPEG and noticeably better than WebP, with excellent quality retention even at low bitrates. It supports transparency, wide color gamut, and HDR. Support is around 92% of browsers and climbing. The catch is encoding cost — AVIF takes longer to compress, so I reserve it for the images that matter most: hero images, product shots, anything big and prominent where the extra 20-30% size win pays off.
My practical strategy:
- AVIF for large, important images (heroes, product photos) where every KB counts. - WebP for everything else raster — it's the safe modern default. - JPEG/PNG only as fallbacks for the small slice of browsers without modern support.
The MDN image format guide is the authoritative reference if you want the deep technical details on each codec. The numbers vary by image, but the ordering — AVIF smallest, then WebP, then JPEG — holds consistently in my testing.
A couple of practical caveats I've hit. AVIF's quality-versus-size sweet spot is genuinely impressive, but at very aggressive compression it can smear fine detail and skin tones in a way that's worse than JPEG at the same file size — so don't blindly crank the compression; eyeball the output. WebP's lossless mode is excellent for graphics that you'd otherwise ship as PNG, often 25%+ smaller, and it keeps transparency, so for UI assets with sharp edges I reach for lossless WebP before PNG now. Animated GIFs are another easy win: both WebP and AVIF do animation far more efficiently than GIF, which is an ancient format that produces enormous files. If you've got a heavy animated GIF dragging down a page, converting it to animated WebP or a short muted video is usually a 90%+ size cut. The general theme is that the modern formats aren't just "smaller JPEG" — they each replace a different legacy format, and knowing which replaces which is how you pick correctly.
Serving Them: The Fallback Stack
Photo by Unsplash on Unsplash
```html <picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="Product on a desk" width="1200" height="630"> </picture> ```
The browser reads top to bottom and uses the first `<source>` it understands. A modern browser grabs the AVIF; an older one falls through to WebP, then to the JPEG in the `<img>`. The `<img>` is the mandatory fallback and the element that actually renders, so its `alt`, `width`, and `height` matter for accessibility and layout stability.
A few hard-won rules:
- Always set explicit `width` and `height` (or `aspect-ratio` in CSS). Without them the browser doesn't reserve space and your layout jumps as images load — a Cumulative Layout Shift penalty. I dug into that in the CSS aspect-ratio property guide. - Don't lazy-load your LCP image. The hero is usually your Largest Contentful Paint element; `loading="lazy"` on it delays the most important paint. Lazy-load below-the-fold images only. - Generate the variants at build time, not by hand. Tools like Sharp, Squoosh, or your framework's image component produce the AVIF/WebP/fallback set automatically.
For inline image work — turning a small icon into a base64 string to embed directly — the ToolsFuel image to Base64 converter does it in the browser, and the broader free tools directory has the rest of the image and CSS utilities I reach for. Pick the right format, serve it with a proper fallback, and your images stop being the thing that drags your page speed down.
Frequently Asked Questions
What's the best image format for the web in 2026?
There's no single best format — it depends on the asset. For logos, icons, and simple illustrations, SVG wins because it scales infinitely at tiny file sizes. For photos and complex raster images, serve AVIF first (smallest), WebP second (best all-rounder, ~96% browser support), with JPEG or PNG as fallbacks. Use the picture element so each browser picks the best version it supports.
Is AVIF better than WebP?
AVIF compresses smaller — roughly 50% below JPEG versus WebP's 25-35% — with excellent quality even at low bitrates, plus wide color and HDR support. The tradeoffs are slower encoding and slightly lower browser support (around 92% versus WebP's 96%). I use AVIF for large, important images like heroes and product shots, and WebP as the safe default for everything else raster.
When should I use SVG instead of PNG?
Use SVG for anything geometric — logos, icons, simple illustrations — because it's a vector format that stays sharp at any size and usually weighs just 1-3KB versus 25-50KB for a PNG. SVG also lives in the DOM, so you can style and animate it with CSS. Never use SVG for photographs; that's where raster formats like WebP and AVIF belong. For inline icon work, the [ToolsFuel image to Base64 converter](/tools/image-to-base64) helps when you want to embed small assets directly.
Do I still need JPEG and PNG?
Yes, mainly as fallbacks. JPEG stays the universal-compatibility choice for photos in email and documents, while PNG handles lossless graphics, screenshots, and sharp-edged transparency. In a modern site you'll typically serve the WebP or AVIF version first and keep JPEG/PNG at the bottom of the picture element's fallback chain for the small slice of browsers without modern support.
How do I serve different image formats to different browsers?
Use the HTML picture element with multiple source tags ordered AVIF, then WebP, then a JPEG or PNG inside the img fallback. The browser reads top to bottom and uses the first format it understands. Always set explicit width and height on the img to prevent layout shift, which ties into the [CSS aspect-ratio property](/blog/css-aspect-ratio-property-explained) for reserving space cleanly.
Should I lazy-load all my images?
No — never lazy-load your Largest Contentful Paint image, which is usually the hero. Adding loading="lazy" to it delays the most important paint and hurts your Core Web Vitals. Lazy-load only below-the-fold images that aren't visible on initial load. The hero should load eagerly with explicit dimensions so it paints fast and doesn't shift the layout.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools