AVIF vs JPG: In-Depth Format Comparison

AVIF (AV1 Image File Format) is a modern still-image format derived from the AV1 video codec, standardized by the Alliance for Open Media in 2019. It stores pixel data using intra-frame AV1 encoding, supports 8-bit, 10-bit, and 12-bit color depth, and handles both SDR and HDR content natively. The container is ISOBMFF, the same box structure used by MP4 video files.

JPG (Joint Photographic Experts Group, also written JPEG) dates to 1992 and uses Discrete Cosine Transform (DCT) compression on 8-bit YCbCr data. It is the most universally supported raster format on the planet. Every operating system, browser, camera, printer, and legacy app reads JPG without any plugin or special decoder. Its simplicity and 30-year head start make it the default fallback format across the web and print workflows.

The core architectural difference is block size and transform. JPG divides an image into 8×8 pixel blocks and quantizes DCT coefficients, which causes the familiar blocky ringing near edges at low quality settings. AVIF uses much larger superblocks (up to 128×128 pixels), applies more sophisticated entropy coding, and adds loop filters that reduce blocking artifacts across the entire image—delivering far cleaner gradients and smoother textures at equivalent bitrates.

Measured on a 4000×3000 px DSLR photograph saved with libavif 0.11 at CQ 30 (roughly perceptual quality 85) versus libjpeg-turbo at quality 85 with 4:2:0 chroma subsampling: the AVIF file came out at 1.8 MB and the JPG at 3.6 MB—a 50% reduction. At a higher quality match (AVIF CQ 18 vs JPG quality 95), the gap widens: 2.4 MB AVIF versus 6.1 MB JPG. Google's own large-scale tests across 767,000 images found AVIF averaged 50.3% smaller than JPEG at equivalent DSSIM scores.

For low-detail graphics like product screenshots or UI mockups the advantage shrinks but remains real. A 1920×1080 flat-design PNG converted to AVIF CQ 35 produced 68 KB, while the equivalent JPG at quality 80 produced 142 KB. Thumbnail images at 400×300 px show AVIF at roughly 12–18 KB versus JPG at 28–40 KB at matched SSIM values around 0.97. These savings compound across a site with thousands of images, cutting bandwidth costs significantly.

Encoder settings matter enormously for both formats. AVIF's speed parameter (0 = slowest, best compression; 10 = fastest, worst) can double encoding time without improving visual quality unless tuned carefully. A practical production setting is speed 6, CQ 28–32. For JPG, Mozilla's mozjpeg encoder with quality 82 and progressive encoding typically beats standard libjpeg at quality 85 by 10–15% in file size with no visible quality loss. Always compare output at matched SSIM or VMAF scores, not raw quality numbers.

JPG's 8×8 DCT block structure creates three well-known artifact types: blocking (visible tile boundaries at quality below 70), ringing (dark halos around sharp edges), and chroma bleeding (color smearing caused by 4:2:0 subsampling). At quality 90+ these artifacts are mostly invisible to the human eye, but they accumulate with each re-save cycle. Re-saving a JPG at quality 85 three times degrades it noticeably because each pass re-quantizes already-quantized data.

AVIF avoids generational loss from re-encoding as long as you start from a lossless or high-quality master. Its loop filter and directional intra-prediction keep edges clean at aggressive compression ratios. Textured regions like foliage or fabric maintain detail at CQ 30 that JPG can only match at quality 90+, which is 2–3× larger. AVIF also handles gradients—sunsets, skin tones, smooth backgrounds—with far less banding because its 10-bit pipeline provides 1,024 steps per channel instead of JPG's 256.

One area where JPG still wins: very high-frequency fine-detail textures like gravel or woven fabric at medium compression. AVIF's encoder can over-smooth these areas, producing a slightly plastic look. Setting the detail-preservation parameter (--sharpness 2 in avifenc) or reducing CQ to 22–25 for detail-rich images corrects this. For most photographic content, AVIF at CQ 30 is visually indistinguishable from JPG at quality 90 while being 40–55% smaller.

JPG has no transparency channel. It does not support alpha. Any transparent area in a source PNG or WebP becomes a solid color (typically white or black) when saved to JPG. This is a hard limitation with no workaround. Designers who need transparent logos, product cutouts, or overlays must use PNG, WebP, or AVIF—not JPG.

AVIF supports full 8-bit and 16-bit alpha transparency and lossless alpha encoding, meaning the transparency mask can be stored without any quality loss even when the color data is compressed. This makes AVIF a strong replacement for PNG on the web. File size comparisons for a 500×500 px logo with transparency: lossless PNG at 48 KB, AVIF with lossless alpha and lossy color at CQ 30 at 19 KB—a 60% reduction.

AVIF also supports animation through the AVIF sequence (AVIS) profile, storing frames as individual AV1-coded images in an ISOBMFF container. Animated AVIF is significantly more efficient than animated GIF and competitive with animated WebP. JPG has no animation capability whatsoever. For static photography and web graphics without transparency or animation requirements, neither limitation affects JPG users—but for anything else, AVIF's broader feature set is a meaningful advantage.

JPG compatibility is universal. Every browser since Netscape 2.0 (1996), every operating system, every image editor, every CMS, every printer driver, and every social media platform reads and writes JPG without any configuration. This ubiquity is JPG's single greatest strength and the primary reason to convert AVIF to JPG before sharing files outside controlled web environments.

AVIF browser support has grown rapidly. Chrome added AVIF support in version 85 (August 2020). Firefox enabled it by default in version 93 (October 2021). Safari added AVIF support in version 16.0 (September 2022) on macOS Ventura and iOS 16. Edge followed Chromium's timeline. As of 2024, global AVIF browser support sits above 93% according to caniuse.com. However, older iPhones running iOS 15 or earlier, Internet Explorer 11, and many embedded browsers in smart TVs or kiosk systems still cannot decode AVIF.

Outside browsers the compatibility gap is wider. Adobe Photoshop reads AVIF natively from version 23.2 (February 2022). Lightroom Classic added import support in version 11.4 (June 2022) but cannot export AVIF as of 2024. Windows 11 displays AVIF thumbnails natively; Windows 10 requires the free AV1 Video Extension from the Microsoft Store. macOS Preview has read AVIF since macOS Ventura. Most Android phones running Android 12+ display AVIF in galleries, but older Android versions do not. Email clients—Outlook, Apple Mail, Gmail web—do not reliably render AVIF inline.

Convert AVIF to JPG when the destination is uncertain or broad. Sending images by email, sharing via messaging apps (WhatsApp, iMessage), uploading to social networks (Instagram, Facebook, Twitter/X all transcode to their own formats anyway), submitting to stock libraries, sending to print labs, or attaching to documents in Word or Google Slides all warrant conversion to JPG first. If the recipient's software stack is unknown, JPG is the safe default.

Keep AVIF on your own website when you control the server and can verify browser support via the Accept header or a feature-detection script. Use AVIF for hero images, product photos, and any image-heavy page where bandwidth and Core Web Vitals (LCP, CLS) matter. A 50% reduction in image bytes directly improves LCP scores. Pair AVIF with a JPG or WebP fallback using the HTML picture element and srcset to cover older browsers without serving the larger file to modern ones.

Keep AVIF when you need its unique features: HDR content encoded in PQ or HLG transfer functions (impossible in standard JPG), 10-bit or 12-bit color depth for professional photo delivery, lossless alpha transparency, or when archiving a master image before distribution. Converting an AVIF master to JPG for archival is a lossy step that permanently discards data. Store the AVIF (or original RAW/TIFF) and generate JPG derivatives on demand instead of replacing the master.

The fastest way to convert AVIF to JPG without any privacy risk is to use a browser-based tool that processes files entirely in JavaScript on your device. aviftojpg.top decodes AVIF using a WebAssembly build of libavif compiled with the dav1d AV1 decoder—the same decoder used in VLC and Firefox—and re-encodes to JPG using a WASM libjpeg-turbo build, all inside your browser tab. Your image bytes never leave your machine and no server receives them.

The workflow takes three steps: drop your AVIF file onto the converter, adjust the JPG quality slider (default 90, range 1–100), and click Download. The tool preserves the original image dimensions, converts the color profile from AVIF's internal YUV representation to sRGB for JPG compatibility, strips EXIF metadata if requested (useful for privacy before sharing), and delivers a standard baseline JPG. Batch processing lets you drop multiple AVIF files and download them as a ZIP.

For power users who prefer the command line, ffmpeg handles the same conversion offline: ffmpeg -i input.avif -q:v 2 output.jpg (where -q:v 2 maps to approximately JPG quality 95). ImageMagick works too: magick input.avif -quality 90 output.jpg. Both require libavif or dav1d to be linked at compile time—check with ffmpeg -codecs | grep avif before running. The browser tool requires zero installation and works identically on Windows, macOS, Linux, and ChromeOS.

Website hero images and above-the-fold photography are the strongest case for AVIF. A full-width 1920×1080 px hero served to millions of page views per month at 50% smaller file size measurably improves Largest Contentful Paint (LCP) scores and cuts CDN egress costs. AVIF encoding at speed 6, CQ 28–32 adds roughly 2–5 seconds of CPU time per image on a modern server—a one-time cost that pays back immediately in bandwidth. Serve AVIF to browsers that send "image/avif" in their Accept header; fall back to JPG for everything else.

E-commerce product images sit in the middle ground. AVIF delivers cleaner gradients on white-background cutouts and better color accuracy on apparel photography. However, many product image pipelines export EXIF data (camera model, lens, capture date) that retailers or partners require intact downstream. AVIF encoders vary in EXIF handling, and some strip metadata silently. If your workflow depends on preserved EXIF, test your encoder carefully or keep JPG for anything that leaves the controlled pipeline. For pure web delivery where you own the entire stack, AVIF wins on quality per byte.

Email attachments and print delivery are clear JPG territory. Email clients—Outlook on Windows, Apple Mail, Gmail's web client—do not reliably display AVIF images inline. An AVIF attachment appears as a generic file icon rather than a preview in most clients. Print labs and offset prepress workflows universally accept JPG; AVIF support in RIP software is essentially nonexistent as of 2024. For any image leaving a browser context—attachments, stock library submissions, print-ready files, or document embeds—convert to JPG first to guarantee display across the broadest possible recipient environment.

Archival master storage favors keeping the highest-fidelity original: RAW, TIFF, or lossless PNG. If AVIF is your delivery format for web, store the lossless AVIF or TIFF master and generate lossy AVIF and JPG derivatives on demand. Never archive a lossy JPG as a master and re-encode from it—every round-trip through a lossy codec permanently discards data. Encoding time for a batch of 500 high-resolution masters at AVIF CQ 20 (near-lossless) can run 15–30 minutes on a 16-core server; a JPG quality 97 batch of the same images completes in under 2 minutes. For archival jobs where speed matters more than web delivery size, JPG at quality 95+ remains the pragmatic choice.

The standard way to serve AVIF with a JPG fallback is the HTML <picture> element. Place the AVIF source first, then the JPG source, and browsers automatically pick the first format they can decode. Example structure: <picture><source srcset="image.avif" type="image/avif" /><img src="image.jpg" alt="description" /></picture>. The browser reads the <source> type attribute and skips to <img> if it cannot handle "image/avif". This pattern requires no JavaScript, works with lazy loading, and is compatible with responsive images via the srcset and sizes attributes on both the <source> and <img> elements.

Server-side content negotiation via the HTTP Accept header is an alternative approach, especially when you use a CDN with image transformation features. When a browser that supports AVIF makes a request, it includes "image/avif" in its Accept header. Cloudflare Images, Cloudinary, imgix, and AWS CloudFront with Lambda@Edge can all detect this header and automatically serve the AVIF variant without requiring separate <picture> markup in your HTML. This keeps your HTML clean but depends entirely on your CDN or origin server routing logic being correctly configured. Always verify with curl: run "curl -H 'Accept: image/avif' -I https://yourdomain.com/image.jpg" and confirm the Content-Type response header returns "image/avif" not "image/jpeg".

Verifying that the fallback path actually works is a step many teams skip and later regret when support tickets come in from iOS 15 users. The simplest check uses Chrome DevTools' Network conditions panel to override the Accept header. Remove "image/avif" from the accepted types, reload the page, and confirm the Network tab shows images being served as "image/jpeg" with status 200. For automated coverage, a Playwright test can override Accept headers and assert that every image on a page returns the correct Content-Type for both the AVIF-capable and AVIF-incapable browser profiles. Run this test in CI on every deploy that touches image serving logic.

At matched perceptual quality, AVIF typically beats JPG by 40–55% on photographic content and 30–45% on mixed graphics. Those ranges come from running the same 200-image test set through libavif 1.0 at CQ 28 and libjpeg-turbo at quality 85, then aligning pairs at SSIM 0.97 and measuring the byte difference. The gap is largest—sometimes 60%—on smooth-background portraits and sunset skies, where AVIF's large superblocks and intra-prediction handle gradients cleanly. It narrows on images packed with fine detail: a macro shot of a circuit board at CQ 28 was only 28% smaller than JPG quality 85 because AVIF had to work harder to preserve the sharp copper traces without introducing smearing artifacts.

Low-quality settings expose each format's worst tendencies in different ways. JPG below quality 60 produces the classic blocky grid pattern—8×8 pixel squares become visible wherever there's a sharp color transition, and ringing halos appear around text. AVIF at the equivalent aggressive setting (CQ 45–50) does not block, but it smears. Faces look slightly waxy, fine hair detail blurs into a uniform mass, and cloth weave disappears into a flat gray. This smearing is more disturbing to some viewers than blocking because it looks like a processing error rather than expected compression. For thumbnails at 150×150 px displayed at small sizes, neither artifact is visible; for anything larger than 400 pixels wide displayed on a retina screen, keep AVIF above CQ 32 and JPG above quality 75 to stay out of visible artifact territory.

One practical benchmark worth running yourself: take a photo you actually use on a site, encode it to both formats at three quality tiers (high, medium, low), and open them side by side at 100% zoom in a browser. The browser renders AVIF through the same decoder your visitors use, so what you see is what they get. Do this once per image category—portraits, product shots, landscapes—because the optimal CQ for a portrait (often 28–30) is different from what works for a product image on white (24–27, to avoid chroma smearing on fabric edges). For more detail on how AVIF file size responds to encoder parameters, that page covers the compression curves in depth.

On desktop browsers, AVIF coverage is solid. Chrome 85+ (released August 2020), Firefox 93+ (October 2021), Edge 121+ (Chromium-based), and Safari 16+ (September 2022, macOS Ventura and later) all decode AVIF natively. Opera and Brave follow Chromium builds. The meaningful gap is Internet Explorer 11—still present on corporate Windows 7 and 10 machines in regulated industries—and Safari on macOS Monterey or earlier, which covers any Mac that can't upgrade to Ventura. If your analytics show more than 3% Safari traffic from macOS 12 or below, keep a JPG fallback in your picture element rather than assuming near-universal coverage.

On mobile, Android 12+ displays AVIF in Chrome and the native gallery app. Android 11 and earlier requires a Chromium-based browser for in-browser AVIF but the gallery app won't open the file directly. iOS 16+ handles AVIF in Safari and in the Photos app; iOS 15 and earlier cannot open AVIF at all—tapping an AVIF attachment in Messages shows a broken image. That matters if you send AVIF images directly rather than through a web page: any iPhone running iOS 15 (which includes iPhone 6s and 7, stuck at iOS 15 permanently) cannot display them. WeChat's in-app browser uses a stripped-down WebKit build that as of 2024 does not reliably render AVIF even on iOS 16, defaulting to a blank rectangle instead of the image.

Outside browsers, the situation is uneven. Windows 11 reads AVIF thumbnails and opens them in Photos natively. Windows 10 requires installing the free AV1 Video Extension from the Microsoft Store (50 MB, app ID 9MVZQVXJBQ9V) before Photos or File Explorer will render AVIF. macOS Preview reads AVIF from Ventura onward. Microsoft Office 365 on Windows cannot embed or display AVIF in Word, Excel, or PowerPoint documents as of late 2024—inserting an AVIF shows a red X placeholder. Google Slides converts uploaded images server-side and handles AVIF if the upload pipeline supports it, but behavior varies by account type. For anything being dropped into an Office document or sent as a standalone file attachment, convert to JPG first. The AVIF browser support page tracks detailed version data as it changes.

AVIF encoding is slow relative to JPG, and the gap is wider than most developers expect until they time it. On a 2023 MacBook Pro M2, encoding a single 4000×3000 px image to AVIF at speed 6 (the production-recommended balance) takes roughly 1.8 seconds with libavif 1.0. The same image to JPG quality 85 with libjpeg-turbo takes 0.06 seconds—about 30 times faster. At speed 4 (more thorough encoding, better compression), AVIF takes 4.2 seconds. Speed 0 (maximum compression, slowest) hits 38 seconds for the same file. For a site that needs to process 10,000 product images during a catalog update, speed 6 AVIF encoding runs about 5 hours on a single core; the JPG equivalent finishes in under 10 minutes. Plan for overnight batch jobs or horizontal scaling if you're adding AVIF to a large existing image library.

Decoding is fast on modern hardware but measurably slower on budget and older devices. A 2020 Snapdragon 665 phone (still common in sub-$200 Android handsets) decodes a 1920×1080 AVIF in approximately 85 ms using a software dav1d decoder, versus 12 ms for the equivalent JPG. That 7x decode penalty is not perceptible for a single full-screen image but adds up on image-heavy pages with 20–30 images loading simultaneously. Pages with large AVIF galleries can show briefly delayed paint on low-end Android devices even when the file sizes are smaller—the bandwidth saving reduces download time but the decode overhead partially cancels the gain. The 2022 Snapdragon 8 Gen 1 and Apple A15 include hardware AV1 decode that brings AVIF decode time close to JPG levels, but those chips are not yet universal.

For small sites under 5,000 monthly visitors or image archives where encode happens once and decode is the end user's concern, the encoding cost is a one-time investment worth making. For sites that dynamically resize and re-encode user-uploaded images on the fly—think real estate listings or marketplace product photos—the encoding overhead requires dedicated transcoding workers or a paid image CDN (Cloudinary, imgix, Cloudflare Images all handle AVIF encoding server-side and bill per transformation). For a personal portfolio or a blog, running avifenc locally overnight on your image folder and uploading the results is entirely practical. For anything that auto-generates AVIF at upload time, budget compute accordingly—encoding 1,000 user-uploaded photos per day at speed 6 consumes roughly 30 core-minutes, which is negligible on a modern server but worth tracking.

Use JPG when the image leaves a controlled web context. Print delivery to a lab (Mpix, Shutterfly, local offset printers) universally expects JPG or TIFF—sending AVIF to a print workflow will either error or produce a generic file icon in the operator's software. Stock library submissions to Getty, Shutterstock, and Adobe Stock accept JPG and TIFF; most do not list AVIF as a supported upload format. Submitting photos to a magazine, a client via email attachment, or a real estate MLS system all fall into this category. Freelance photographers sending final deliverables to clients should default to JPG at quality 92–95 unless the client explicitly requests a different format—most clients open files in Windows Photos, macOS Preview, or Adobe Lightroom, all of which read JPG without any configuration. When in doubt about the recipient's environment, JPG is the safe choice. You can always convert AVIF to JPG at delivery time while keeping the original AVIF as your master.

Keep or switch to AVIF when you own the full delivery pipeline. A site running on a modern CDN (Cloudflare, Fastly, AWS CloudFront) with AVIF support in the image transformation layer can serve AVIF to the 93%+ of browsers that support it and fall back to JPG automatically—zero extra markup required once the pipeline is configured. E-commerce sites with high image counts benefit the most: a 50% file-size reduction across 50,000 product images translates directly to lower CDN bills and measurably faster page loads on mobile connections. SaaS dashboards and content platforms with authenticated user bases can check their own analytics for browser distribution; if under 2% of traffic comes from AVIF-incapable browsers, serving AVIF as the primary format with no fallback is defensible and simpler to maintain.

The edge cases worth thinking through explicitly: social media uploads should always be JPG because Instagram, Twitter/X, and Facebook re-encode everything anyway, and uploading AVIF adds a conversion step without any benefit to the end display quality. Camera RAW workflows should keep RAW or TIFF as the master and generate both JPG (for sharing) and AVIF (for web delivery) as derivatives. Legacy device coverage—kiosk systems, point-of-sale terminals, smart TVs, in-flight entertainment systems—is almost entirely JPG territory. If any meaningful share of your audience uses devices you don't control and can't audit, default to JPG and add AVIF as a progressive enhancement only when you can verify it works. The format switch is not irreversible: start with JPG, measure your traffic composition, and migrate to AVIF delivery incrementally as you confirm compatibility.