AVIF vs WebP vs JPG: The Modern Image Format Showdown
Why This Comparison Actually Matters
Don't mistake image formats for a cosmetic choice. They're not. A single poorly chosen format on a high-traffic product page can add 200–400 KB per image. That compounds into seconds of extra load time and measurable drops in conversion. Google's Core Web Vitals directly penalize slow Largest Contentful Paint scores, and images are the usual suspect. Choosing between AVIF, WebP, and JPG has real consequences for SEO, bandwidth bills, and whether users stick around. JPG has dominated photography since the mid-90s. It works everywhere, encodes fast, and every developer knows how to handle it. Google’s WebP arrived in 2010 as its replacement, promising better compression for the same quality. The newcomer is AVIF, standardized in 2019 by the Alliance for Open Media. It pushes compression even further by borrowing tech from the AV1 video codec. The goal here isn't to declare one format the winner. That's pointless. The goal is to understand the specific tradeoffs so you can make the right call for *your* project, not just follow some outdated advice from 2021. We'll break down the real-world compression, browser support, and hidden costs like encoding speed, giving you the context to use each format effectively—and know when it's time to convert.
Compression Performance: The Numbers Behind the Hype
Yes, modern formats are dramatically smaller than JPG. That part of the hype is true. But how much smaller depends on the image, the encoder, and the quality you're aiming for. For a typical photograph, WebP usually lands 25–35% smaller than a JPG of equivalent visual quality. AVIF goes even further, often hitting 40–55% smaller than the JPG, which is about 15–25% smaller than the WebP. That means a 180 KB product photo (JPG, quality 85) might become a 120 KB WebP or a 90 KB AVIF. The savings are real. But you can't just compare quality numbers across formats. They aren't equivalent. A "quality 85" JPG isn't the same as a "quality 85" WebP. Dropping a JPG from 85 to 75 in ImageMagick might slash the file size, but it will also introduce blocky artifacts in gradients and skies. WebP uses a 0–100 scale where 80 is a good starting point, roughly equivalent to a JPG 85. AVIF uses a Constant Rate Factor (CRF) scale, usually 0–63, where lower is better. For web photos, a CRF of 30–40 is often the sweet spot. The story changes for graphics like UI screenshots, logos, or infographics. PNG has been the go-to for its lossless quality, but WebP's lossless mode consistently produces files 20–30% smaller. AVIF's lossless mode is less mature and can sometimes create *larger* files than WebP lossless for this type of content. Don't assume AVIF wins everywhere. The Squoosh team at Google ran tests that confirmed AVIF's general superiority on compression, but they also found the advantage shrinks when you're working with source images that are already heavily compressed. If you're re-converting a pile of old JPGs instead of working from high-quality originals, you'll see diminishing returns. Garbage in, slightly smaller garbage out.
Browser and Platform Support: Where Things Get Complicated
Let's be clear: JPG support is universal. Every browser, OS, image viewer, CMS, CDN, and email client just handles it. Don't underestimate that advantage; it's a level of ubiquity that newer formats simply can't match yet. For web use, WebP support is now excellent. As of 2024, every major browser—Chrome, Firefox, Safari (since version 14), Edge, Opera—is on board. Global support is over 97% on caniuse.com. The only real holdouts are ancient Safari versions on iOS 13 and below, which might be a non-issue for your audience. AVIF support is good, but you need to be more careful. Chrome has been on board since version 85 (2020), Firefox since 93 (2021), and Safari finally joined with version 16 (2022). This covers most users, but you can still hit snags with Edge on older Windows 10 builds or certain Android WebViews. Global support hovers around 93-95%. That sounds great, but for a high-traffic site, the 5-7% of users who get a broken image is a very real problem. Outside the browser, things get complicated. For desktop apps, mobile apps, or emails, support is a patchwork. macOS has supported AVIF since Ventura (13.0). Windows 11 supports it, but Windows 10 needs a codec from the Microsoft Store. Android has support since version 12, and iOS since 16. This is all irrelevant if you're using the HTML `<picture>` element with proper fallbacks, but it's a major headache if you expect users to download and open these files themselves. The only sane strategy for a production website is to serve images in a cascade: AVIF first, then WebP as a fallback, and finally JPG for everything else. You can implement this using the `<picture>` element's `source` tags with `type` attributes, or by checking the `Accept` header on your server. Don't just serve AVIF and hope for the best.
Encoding Speed and Tooling: The Hidden Cost
There's a hidden cost to AVIF's incredible compression: time. AVIF encoding is brutally slow compared to JPG or WebP, and that has real-world consequences for your workflow. Let's look at the numbers. Encoding a 2000×1500 photo to JPG (quality 85, libjpeg-turbo) might take 50-80 milliseconds on a modern machine. The same image to WebP (quality 80, libwebp) takes 200-400 milliseconds. But encoding to AVIF (CRF 32, speed 6) can take anywhere from 2 to 8 *seconds*. And if you crank the encoder to its slowest, highest-quality setting, you could be waiting 30 seconds or more for a single image. For a batch of 500 product images, that's the difference between a 5-minute coffee break and a 4-hour wait. If you're generating images on-the-fly, as some CDNs do, that kind of encoding overhead can add unacceptable latency unless your caching game is perfect. The libavif encoder has a speed setting from 0 (slowest, best compression) to 10 (fastest, worst). Speed 6 is the standard recommendation, a good compromise between file size and your own sanity. Speed 10 is nearly as fast as WebP, but you sacrifice a lot of AVIF's compression advantage. CocoConvert handles this complexity for you on the server, but the physics still apply: large batches of AVIF conversions will take significantly longer than WebP or JPG jobs. If you're in a hurry, WebP is often the more practical choice, even if AVIF could shave off a few more kilobytes. Tooling for WebP is mature and stable; cwebp, Squoosh, ImageMagick, and the Node.js Sharp library all have robust support. AVIF tooling is getting there—Sharp added support in v0.27.0 and ImageMagick uses libheif—but anyone who has fought a library dependency issue knows that "catching up" can mean encountering strange bugs and version conflicts that simply don't exist in the world of JPG and WebP.
Image Quality at Low Bitrates: Where Formats Diverge Most
At high quality settings, most compressed images look good. The real test comes at low bitrates, when you're aggressively squeezing every last byte out of a file. This is where the formats truly show their colors, and the differences are obvious. Heavy JPG compression is infamous for its blocky artifacts. At quality 40-50, smooth gradients in a blue sky fracture into a patchwork of squares. Text gets a fuzzy, ringing halo. We've all seen them, and they're ugly. WebP, at the same low file size, tends to blur rather than block. It smooths away fine details. This can be a more pleasing artifact for portraits, where the blur looks more natural than JPG's harsh blocks. For images with sharp lines or text, however, that same blur can be a major drawback. This is where AVIF really shines. At low bitrates, it demolishes the other two. Its AV1-based encoding is simply better at preserving detail and handling gradients gracefully. An AVIF image at 50 KB just looks cleaner than a WebP or JPG of the same size. AVIF's true advantage isn't at quality 90, where everything is fine; it's at quality 50-60, where you're pushing the limits. The perceptual metrics back this up. A 1200×800 landscape compressed to 50 KB might score a DSSIM of 0.008 for JPG, 0.005 for WebP, and 0.003 for AVIF (lower is better). Those aren't just numbers; they represent visible improvements. If you have a strict file size budget, AVIF will consistently give you the best-looking image. There is one exception: fine film grain or natural textures. AVIF's encoder can be overzealous in smoothing these details, resulting in a slightly artificial, plastic-y look in some high-ISO photos. Always test on your own images; don't assume AVIF is a magic bullet for every type of content.
Practical Use Cases: Matching Format to Purpose
Theory is nice, but where should you actually use each format? Here’s a pragmatic guide for common scenarios. **Website Hero & Product Photos:** Go with AVIF, falling back to WebP, then JPG. You control the environment, so you can use the `<picture>` element to serve the best format. The bandwidth savings are huge. A tool like CocoConvert can batch-convert your JPG originals to both AVIF and WebP to make this easy. **Email Images:** JPG. Full stop. Email clients are a wasteland of inconsistent rendering. Neither AVIF nor WebP has reliable support in Outlook, Apple Mail, or Gmail. Sending a WebP will just show a broken image to a huge chunk of your audience. **Social Media Uploads:** Stick with high-quality JPG. Every platform (Instagram, Twitter/X, Facebook) is going to re-encode your image no matter what you upload. Give their encoders the best possible source material to work with; uploading a pre-compressed AVIF gains you nothing. **Print or Archival:** Neither. Use a lossless format like TIFF or PNG for your originals. If you must send a compressed preview, a high-quality JPG (90-95) is the universal standard that any print shop or editor can open. **Mobile App Assets:** It depends on your minimum OS target. If you're building for Android 12+ and iOS 16+, AVIF is a great choice. For broader support, WebP is the safer bet, working back to Android 4.0 and iOS 14. **CMS Content:** Be cautious with AVIF. When non-technical users are uploading images, you want the most reliable workflow. Many CMS media libraries and thumbnail generators still don't handle AVIF properly. JPG and WebP are far more practical and less likely to cause support tickets about broken image previews.
How to Convert Between These Formats (and What to Watch For)
Converting between these formats is easy with the right tools, but a few landmines can ruin your batch jobs if you're not careful. The cardinal rule of conversion: always start from the highest-quality source. Converting a JPG to an AVIF doesn't magically restore the detail that JPG compression already destroyed. It just wraps the same degraded data in a new format. If you have RAW or TIFF originals, use them. If all you have is a JPG, converting it to AVIF will make the file smaller, but it won't make the image look any better. Using a tool like CocoConvert simplifies the process: upload, pick a format, and download. The default quality settings for JPG-to-WebP are tuned to maintain visual quality. For JPG-to-AVIF, the defaults strike a balance between file size and quality, but you should consider requesting higher quality for images that will be displayed large and scrutinized by users. Let's be upfront about a limitation: CocoConvert doesn't handle animated formats. Converting animated WebP to animated AVIF is a whole different beast, involving frame timing and color palettes. For that, you'll need to break out a command-line tool like FFmpeg. Watch out for transparency. JPG doesn't support it, period. If you convert a transparent PNG or WebP to JPG, the background will be filled in with a solid color, usually white or black. Both AVIF and WebP handle transparency (the alpha channel) just fine, so converting between them preserves it. Just make sure you don't accidentally pass a transparent image through a JPG conversion step in your pipeline. Finally, a dose of pragmatism. Before you generate AVIF and WebP versions for every image, ask yourself if you really need both. Generating two formats doubles your processing time and storage. For many sites, simply standardizing on WebP is a massive improvement over JPG and covers 97%+ of users with far less complexity. AVIF is powerful, but only add it if your bandwidth bill truly justifies the extra work.