AVIF vs WebP vs JPG: The Modern Image Format Showdown
Why This Comparison Actually Matters
Image formats are not a cosmetic choice. A single poorly chosen format on a high-traffic product page can add 200–400 KB per image, which compounds into seconds of extra load time and measurable drops in conversion rates. Google's Core Web Vitals directly penalize slow Largest Contentful Paint scores, and images are the most common culprit. So when you're choosing between AVIF, WebP, and JPG, you're making a decision with real consequences for SEO, bandwidth costs, and user experience. JPG has been the dominant format for photographs since the mid-1990s. It works everywhere, encodes quickly, and every developer on earth knows how to handle it. WebP arrived from Google in 2010 as a modern replacement, offering better compression at equivalent quality. AVIF is the newest of the three — standardized in 2019 by the Alliance for Open Media — and it pushes compression efficiency even further using the AV1 video codec's intra-frame encoding. None of these formats is universally superior. Each has a context where it makes the most sense, and understanding the tradeoffs is how you make the right call rather than just following whatever a blog post told you to do in 2021. This article breaks down compression performance, browser support, encoding speed, and practical use cases so you can make an informed decision — and know exactly when to convert between them.
Compression Performance: The Numbers Behind the Hype
The most cited claim about modern formats is that they're dramatically smaller than JPG. That's broadly true, but the magnitude varies considerably depending on image content, encoder settings, and quality targets. For photographic images at visually equivalent quality, WebP typically achieves 25–35% smaller file sizes than JPG. AVIF pushes that further, often reaching 40–55% smaller than JPG and roughly 15–25% smaller than WebP. A product photograph that weighs 180 KB as a JPG at quality 85 might come in at 120 KB as WebP at comparable quality, and around 90 KB as AVIF. Those numbers come with an important caveat: encoder quality. JPG quality settings are not linear — dropping from quality 85 to quality 75 in Photoshop or ImageMagick cuts file size substantially but introduces visible artifacts in gradients and sky tones. WebP uses a 0–100 quality scale where quality 80 is roughly comparable to JPG quality 85. AVIF uses a CRF (Constant Rate Factor) scale, typically 0–63 in tools like libavif, where lower numbers mean higher quality — CRF 30–40 is a common sweet spot for web photography. For graphics with flat colors, text, and hard edges — think UI screenshots, infographics, or logos — the comparison shifts. PNG has traditionally dominated this space because it's lossless, but WebP lossless mode often beats PNG by 20–30%. AVIF lossless is less mature and sometimes produces larger files than WebP lossless in this category, which is a genuine limitation worth knowing. One practical benchmark: the Squoosh team at Google tested AVIF against WebP and JPG across a diverse image corpus and found AVIF consistently won on compression at quality parity, but the gap narrowed significantly for already-compressed source images. If your source files are already re-saved JPGs rather than originals, you'll see diminishing returns from any format conversion.
Browser and Platform Support: Where Things Get Complicated
JPG support is universal. Every browser, every operating system, every image viewer, every CMS, every CDN, every email client handles JPG without question. That ubiquity is not a small thing — it's a practical advantage that newer formats genuinely cannot match yet. WebP support is now excellent for web use. As of 2024, all major browsers — Chrome, Firefox, Safari (since version 14 in 2020), Edge, and Opera — support WebP. Global browser support sits above 97% according to caniuse.com. If you're serving images on the web and can't use AVIF for whatever reason, WebP is a safe default. The main gap is older Safari versions on iOS 13 and below, which affects a small but non-zero percentage of users depending on your audience. AVIF support is strong but not yet complete. Chrome has supported it since version 85 (released August 2020). Firefox added full support in version 93 (October 2021). Safari added AVIF support in version 16 (September 2022). That covers the vast majority of current browser installs, but Edge on older Windows 10 builds and some Android WebView implementations can still trip you up. Global support is around 93–95%, which sounds high until you realize 5–7% of a large site's traffic is a significant absolute number of users. For non-web contexts — desktop applications, mobile apps, email, print workflows — the picture is messier. macOS supports AVIF natively since Ventura (13.0). Windows 11 supports it natively. Windows 10 requires a codec extension from the Microsoft Store. Android has supported AVIF since Android 12. iOS supports AVIF since iOS 16. None of this matters if you're building a web app with a proper fallback strategy using the HTML picture element, but it matters a great deal if you're distributing files that users will open in native applications. The safest production strategy for most websites is serving AVIF to browsers that accept it, WebP as a fallback, and JPG as the final fallback — using the Accept header or the picture element's source srcset with type attributes.
Encoding Speed and Tooling: The Hidden Cost
Compression efficiency doesn't come free. AVIF encoding is significantly slower than JPG or WebP encoding, and this affects your workflow in concrete ways. Encoding a 2000×1500 photograph to JPG at quality 85 using libjpeg-turbo takes roughly 50–80 milliseconds on modern hardware. Encoding the same image to WebP at quality 80 using libwebp takes around 200–400 milliseconds. Encoding to AVIF using libavif at CRF 32 with speed setting 6 (a reasonable balance) takes 2–8 seconds. At the slowest encoder speeds (which produce the smallest files), AVIF encoding can take 30+ seconds per image. For a batch conversion of 500 product images, that difference is the gap between a 5-minute job and a 4-hour job. If you're doing on-the-fly conversion at request time — which some image CDNs do — AVIF's encoding overhead can introduce latency or require aggressive caching strategies. The libavif encoder's speed parameter runs from 0 (slowest, best compression) to 10 (fastest, worst compression). Speed 6 is the commonly recommended default for production use. At speed 6, you get most of the compression benefit without the extreme encoding times. Speed 10 is comparable to WebP in encoding time but gives up a meaningful portion of AVIF's compression advantage. CocoConvert handles AVIF encoding server-side, so you don't have to manage encoder settings manually — but it's worth knowing that large batches of AVIF conversions will take longer to process than equivalent WebP or JPG jobs. For time-sensitive workflows, WebP is often the more practical choice even if AVIF would produce slightly smaller files. WebP tooling is mature. cwebp, Squoosh, ImageMagick, Sharp (the Node.js library), and virtually every modern image processing pipeline supports WebP well. AVIF tooling is catching up — Sharp added AVIF support in version 0.27.0, and ImageMagick supports it via libheif — but you'll occasionally encounter edge cases and version-specific bugs that JPG and WebP workflows simply don't have.
Image Quality at Low Bitrates: Where Formats Diverge Most
The compression efficiency numbers discussed earlier apply at medium-to-high quality settings. At low bitrates — where you're aggressively compressing to hit a target file size — the three formats behave very differently, and the differences become visible to the naked eye. JPG at heavy compression (quality 40–50) produces characteristic blocking artifacts in smooth gradients and ringing artifacts around high-contrast edges. A blue sky becomes a patchwork of slightly different-colored squares. Text on a colored background gets a fuzzy halo. These artifacts are well-understood and predictable, but they're also quite ugly. WebP at equivalent compression levels tends to produce blurrier results rather than blocky ones. Fine detail gets smoothed away, which can look better or worse than JPG artifacts depending on the image content. For portraits, WebP's blurring at low quality often looks more natural than JPG's blocking. For images with sharp geometric lines or text, the blurring can be more distracting. AVIF at low bitrates performs noticeably better than either. Its AV1-based encoding preserves fine detail and handles gradients more gracefully, producing images that look cleaner at the same file size. This is where AVIF's advantage is most pronounced — not at quality 90 where everything looks good, but at quality 50–60 where you're genuinely pushing compression limits. For a concrete example: a 1200×800 landscape photograph compressed to approximately 50 KB might score a DSSIM (a perceptual similarity metric, lower is better) of 0.008 as JPG, 0.005 as WebP, and 0.003 as AVIF. Those numbers translate to real visible differences when you examine the images side by side. If you're optimizing for a specific file size budget rather than a quality level, AVIF consistently delivers better-looking results within that budget. The one area where AVIF's quality advantage shrinks is fine film grain and natural texture. AVIF's encoder sometimes over-smooths these areas in ways that look artificial, particularly in high-ISO photography. This isn't a dealbreaker, but it's worth checking your specific image types rather than assuming AVIF will always win on quality.
Practical Use Cases: Matching Format to Purpose
Given everything above, here's how to think about format selection for common real-world scenarios. For website hero images and product photography where you control the serving environment and can implement a proper fallback strategy, AVIF with WebP fallback is the right answer. The bandwidth savings are real and the browser support is sufficient for most audiences. Use CocoConvert to batch-convert your JPG originals to both AVIF and WebP, then serve them with the picture element. For email images, use JPG. Email clients are a wasteland of inconsistent rendering, and neither AVIF nor WebP has meaningful support in Outlook, Apple Mail, or Gmail's various rendering modes. Sending a WebP image in an email will result in broken images for a substantial portion of recipients. For social media uploads, use JPG. Every major social platform — Instagram, Twitter/X, Facebook, LinkedIn — re-encodes your images anyway. Uploading a high-quality JPG gives the platform's encoder the best source material to work with. Uploading a heavily compressed AVIF doesn't help because the platform will re-compress it regardless. For print or archival purposes, neither AVIF nor WebP is appropriate. Use TIFF or PNG for originals. If you need to share a compressed version, JPG at quality 90–95 is the professional standard that print service providers and photo editors can reliably open. For mobile app assets bundled with an app, check your minimum OS version requirements. If you're targeting Android 12+ and iOS 16+, AVIF is viable. If you need broader compatibility, WebP works well on both platforms back to Android 4.0 and iOS 14. For CMS-managed content where non-technical editors upload images, JPG or WebP is more practical. Many CMS image upload handlers and media library plugins don't handle AVIF reliably yet, and you don't want editors encountering broken preview thumbnails because the CMS's thumbnail generator doesn't support the format.
How to Convert Between These Formats (and What to Watch For)
Converting between AVIF, WebP, and JPG is straightforward with the right tools, but there are a few pitfalls worth knowing about before you run a large batch. The most important rule: always convert from the highest-quality source available, not from an already-compressed version. Converting a JPG to AVIF doesn't recover detail that JPG compression already discarded — it just re-encodes the degraded data in a new container. If you have original RAW files or high-quality TIFFs, start from those. If your only source is a compressed JPG, converting it to AVIF will produce a smaller file but not a better-looking one. With CocoConvert, the conversion workflow is direct: upload your source files, select your target format, and download the results. For JPG-to-WebP conversions, the default quality settings are calibrated to maintain visual equivalence, so you shouldn't need to adjust them for most use cases. For JPG-to-AVIF conversions, the default settings use a moderate CRF value that balances quality and file size — if you're working with images that will be displayed at large sizes and examined closely, you may want to request higher quality output. One limitation worth being honest about: CocoConvert doesn't currently support converting animated WebP to AVIF sequences, or vice versa. Animated image conversion is a separate problem with additional complexity around frame timing and color consistency, and it's not something the current tool handles. For animated image workflows, you'll need a dedicated tool like FFmpeg with the appropriate libavif or libwebp bindings. Also worth noting: transparency (alpha channel) handling differs between formats. JPG doesn't support transparency at all — if you convert a PNG or WebP with transparency to JPG, the transparent areas will be filled with a background color (usually white or black depending on the tool). AVIF and WebP both support alpha channels, so transparency is preserved when converting between them. If your images have transparent backgrounds — product shots, logos, UI elements — make sure you're not accidentally converting through JPG at any point in your pipeline. For batch conversions of more than a few hundred images, consider whether you need both AVIF and WebP outputs or just one. Generating both doubles your storage requirements and processing time. For most websites, having WebP as a single modern format target is simpler to manage and covers 97%+ of users, with AVIF being worth the added complexity only if bandwidth costs are a significant concern.