Updated: July 8, 2026
Converting JPG to AVIF is usually worth it for large web photos — but only when you can serve a JPG or WebP fallback alongside it. AVIF (AV1 Image File Format) often produces much smaller files than JPG at comparable visual quality, because it is built on the AV1 video codec. The exact savings depend on the source image, encoder, quality setting, and content type; in many benchmarks the reduction is substantial, but it is not guaranteed for every file. Do not convert every image blindly: encoding is slow, browser support is around 93–94% globally (not universal), and JPG remains the safer choice for email, print, and fallback delivery. The right pattern is to keep a JPG or PNG master, export AVIF for the web, and serve both with the HTML <picture> element.
Key Takeaways
- AVIF often produces much smaller files than JPG at comparable quality — in many benchmarks roughly 40–50% smaller — but savings vary by image content and encoder settings.
- Browser support is around 93–94% globally (Chrome 85+, Firefox 93+, Opera 71+, Edge 121+, Safari 16.4+ full support), but a fallback is still required.
- Encoding is slow. AVIF's AV1-based encoder is computationally heavy; high-effort presets can be many times slower than JPG or WebP.
- Best use case: large web photos, hero images, and e-commerce product images served through a CDN or
<picture>with a JPG fallback. - Keep JPG for: email, print, legacy software, social uploads, and as the universal fallback inside
<picture>. - Files can get larger: very small or already-optimized JPGs, flat illustrations, and wrong quality settings can all produce a bigger AVIF than the original JPG. Always compare sizes.
What Actually Happens When You Convert JPG to AVIF
A JPG is already a lossy, 8-bit, compressed image. When you convert it to AVIF you are re-encoding already-compressed data into a more efficient container. You do not recover detail the JPG discarded — you repackage the image so the next compression pass is more efficient.
AVIF was released in 2019 by the Alliance for Open Media and uses the AV1 video codec for intra-frame compression. Compared with JPG, AVIF adds support for 10- and 12-bit color, HDR, wide color gamut, alpha transparency, and animation, all in an open, royalty-free format backed by AOMedia. That combination is why, at the same visual quality, AVIF files tend to land well below JPG in byte size.
There is a nuance worth stating plainly: converting JPG → AVIF is a lossy-to-lossy transcode. If your source JPG was saved at low quality, the AVIF will inherit those artifacts and may not shrink as dramatically as a conversion from a high-quality master. The cleanest pipeline is: master (RAW, TIFF, or high-quality PNG/JPG) → AVIF for web, not web-compressed JPG → AVIF.
AVIF vs JPG vs WebP vs PNG: Format Comparison
| Feature | AVIF | WebP | JPG | PNG |
|---|---|---|---|---|
| File size (photos) | Often smallest | Very small | Medium | Large |
| Image quality | Excellent; HDR + wide gamut | Very good; 8-bit mainly | Good; 8-bit only | Lossless |
| Browser support | ~93–94% (modern browsers) | ~95% | Universal | Universal |
| Fallback needed | Yes | Sometimes | No | No |
| Transparency | Yes | Yes | No | Yes |
| Animation | Yes | Yes | No | No (APNG aside) |
| Encode speed | Slow | Medium | Fast | Fast |
| Avoid when | Email, print, small/flat images | Very small flat logos | Not needed on modern web | Photos at scale |
| Best for | Large web photos, hero images | Web images, AVIF fallback | Universal fallback, print, email | Logos, icons, UI graphics |
Pros of Converting JPG to AVIF
Smaller files at the same perceived quality. The headline benefit. On photographic content, AVIF typically produces much smaller files than JPG at a quality level most viewers cannot distinguish from the original. For a site serving large volumes of images, that is a direct reduction in bandwidth, storage, and CDN cost — supported by engineering research from Netflix, Google, and Cloudinary codec comparisons.
Better quality at the same byte budget. If you fix the file size instead of the quality, AVIF can preserve more detail per byte. Independent codec comparisons (see Cloudinary's codec research) show AVIF generally closer to the source than WebP at matched file sizes for complex photographic content, though WebP can outperform AVIF on very simple logos and flat illustrations.
Modern features JPG lacks. AVIF supports 10/12-bit depth, HDR, wide color gamut, and full alpha transparency (per the MDN image format guide and AOMedia specification). If you publish photography where color accuracy and dynamic range matter, AVIF is a genuine upgrade.
Animation in a still-image format. AVIF can encode short image sequences, offering a modern alternative to GIF and animated WebP without the GIF palette and size penalties.
Open and royalty-free. AVIF is an open, royalty-free image format backed by the Alliance for Open Media, which is why browser and CDN adoption has moved quickly.
Core Web Vitals upside. Smaller image payloads generally improve Largest Contentful Paint (LCP), especially on mobile and slower connections. For most sites the byte savings outweigh AVIF's higher decode cost — the file arrives faster than a larger JPG even if decoding takes a few extra milliseconds.
Cons and Limitations
Slow encoding. AVIF's AV1-based encoder is computationally heavy. At high-effort presets a single large image can take significantly longer to export than JPG or WebP, and bulk conversion of a media library can become a real batch job. For production, pick a balanced speed/effort setting rather than maximum effort, or delegate to a CDN.
Higher decode cost. Decoding AVIF takes more CPU than JPG or WebP. On modern hardware the difference is rarely user-visible, and the smaller payload usually compensates, but on very low-end devices the decode time can partially offset the download savings.
Not universal outside the browser. AVIF support in operating systems and applications is still uneven. Support varies by app and OS version; verify before using AVIF for print, email, or archive workflows, since many email clients, photo printers, and older desktop applications still expect JPG or PNG.
Lossy-to-lossy penalty. If your only source is an already-compressed JPG, converting to AVIF re-compresses already-degraded data. You get a size benefit, but not the full quality benefit you would get from converting a high-quality master.
Files can grow. Very small JPGs, already-optimized images, flat illustrations, and incorrect quality settings can all produce an AVIF that is larger than the source. Always compare sizes before publishing.
Metadata and color profile inconsistency. EXIF, ICC color profiles, and XMP can survive the conversion, but tooling support is inconsistent depending on the encoder and version (libavif, ImageMagick, Photoshop). Verify ICC and EXIF on anything where color fidelity or rights metadata matters before publishing.
When JPG to AVIF Is Not Worth It
Not every image benefits from an AVIF conversion. Skip it — or keep both and serve the smaller one — in these situations:
| Scenario | Recommended format | Reason |
|---|---|---|
| Small JPG already under 30–40 KB | Keep JPG | Savings negligible; extra asset adds overhead |
| Already-optimized JPG | Compare sizes | AVIF can be larger; measure before publishing |
| Flat logo, icon, or simple UI graphic | WebP or PNG | WebP often produces a smaller file on flat content |
| Email delivery | JPG / PNG | Email clients rarely support AVIF |
| Print or stock submission | JPG / PNG | Universal interchange format; printers expect it |
| Social media upload | JPG | Platforms re-encode anyway; AVIF support is uneven |
| Sensitive assets needing no cloud processing | Local JPG/PNG + local compression | Keep originals on-device |
| Archive or master file | JPG / PNG / TIFF | AVIF tooling is still maturing; keep an editable master |
AVIF Browser Support and Fallback Requirements
AVIF is supported by all major evergreen browsers, but version details matter:
| Browser | Full support from | Notes |
|---|---|---|
| Chrome | 85 (Aug 2020) | Full support |
| Firefox | 93 (Oct 2021) | Full support |
| Opera | 71 (Sep 2020) | Full support |
| Edge | 121 (Jan 2024) | Full support; earlier versions lacked support |
| Safari (desktop) | 16.4 (Mar 2023) | 16.1–16.3 partial support only |
| Safari (iOS) | 16.4 | Check Can I Use for current iOS specifics |
Source: Can I Use (caniuse.com/avif), StatCounter data June 2026. Global coverage approximately 93–94%; check the current figures before planning fallback strategy as support continues to expand.
That means roughly 6–7% of global sessions — primarily older Safari, legacy enterprise browsers, some in-app webviews, and email clients — still need a JPG or WebP fallback. The standard solution is the <picture> element:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Describe the image for screen readers" loading="lazy" width="1600" height="900">
</picture>
The <img> tag is the fallback and must always be present. Always include explicit width and height to prevent Cumulative Layout Shift (CLS), and use loading="lazy" for below-the-fold images. If you do not want to maintain three files per image, many image CDNs can serve AVIF to capable clients and fall back automatically — check your CDN provider's documentation for format negotiation support.
Best Use Cases for AVIF
| Scenario | Recommended format | Why |
|---|---|---|
| Hero / large web photos | AVIF + JPG fallback | Biggest size win where it matters most for LCP |
| E-commerce product images | AVIF + WebP/JPG fallback | Faster galleries, more products per page |
| Content-heavy blogs / news | AVIF via CDN | Cuts bandwidth at scale with automatic fallback |
| Photography portfolios (HDR) | AVIF | 10/12-bit, wide gamut, HDR support |
| Animated previews (short loops) | AVIF or WebP | Modern alternative to GIF |
| Email, print, stock submission | JPG / PNG | Universal interchange and editor support |
| Logos, icons, simple UI graphics | WebP or PNG | WebP often beats AVIF on very simple images |
| Very small or already-tiny JPGs | Keep JPG | Conversion savings marginal or negative |
How to Test JPG vs AVIF Quality and File Size
Before committing to AVIF in production, run a structured comparison:
| Step | What to check |
|---|---|
| Record source details | Source image, dimensions, original format and quality |
| Note encoder settings | Encoder (avifenc, Squoosh, ImageMagick), quality/CRF value, effort/speed preset |
| Compare file sizes | AVIF vs JPG vs WebP byte counts for the same image |
| Visual inspection | Open both at 100% zoom; look for ringing, banding, or color shift |
| Fallback test | Load page in a browser or context without AVIF support; confirm JPG renders |
| Metadata check | Verify EXIF and ICC color profile survived if they matter for your workflow |
How to Convert JPG to AVIF: A Practical Workflow
- Keep a high-quality master. Start from the best source you have — RAW, TIFF, or a high-quality JPG/PNG — not a web-optimized JPG.
- Export AVIF at a sensible quality. For web photos, a quality range around 60–75 (or equivalent CRF) is a common starting point; tune by eye. Avoid maximum-effort presets for bulk jobs.
- Generate a fallback. Export a JPG (and optionally a WebP) at matching visual quality for the
<picture>fallback path. - Size responsively. Produce a few widths and serve them with
srcsetso mobile devices do not download desktop-sized images. - Compare file sizes. Confirm the AVIF is actually smaller than the JPG — if not, serve the smaller format instead.
- Reduce your output files locally. After you already have AVIF, JPG, and WebP outputs, use a local browser-based compressor such as LessMB to reduce supported image files on-device and compare the result before publishing — without sending your originals to a cloud queue.
- Deploy with
<picture>or a CDN. Either hand-roll the markup or let your CDN negotiate format per browser. - Verify (see the next section).
Common tool categories for the conversion step:
| Tool type | Examples | Good for |
|---|---|---|
| Browser-based converter | Squoosh, online AVIF converters | One-off images, quick previews |
| Local CLI encoder | avifenc, ImageMagick, FFmpeg | Batch jobs, build scripts, precise control |
| CDN / image service | Many major image CDNs | Automatic format negotiation at scale |
| Local, no-upload compressor | LessMB | On-device compression of AVIF/JPG/WebP outputs |
Verify Your AVIF Setup
Before you ship, confirm the format is actually being served and nothing regressed:
- Open the page in Chrome DevTools → Network, filter by
Img, confirm.avifis requested and returnscontent-type: image/avif. - Check the AVIF response is smaller than the equivalent JPG — if not, serve the JPG instead.
- Load the page in an AVIF-unsupported context and confirm the JPG/WebP
<img>src is served with no broken image. - Confirm
widthandheightare set on the<img>so CLS does not increase. - Run Lighthouse / PageSpeed Insights and confirm LCP improved (or at least did not regress) versus the JPG-only version.
- Validate that ALT text, EXIF you need to keep, and ICC color profiles survived the transcode.
- Spot-check on a mid-range Android device to ensure decode cost is not eating the download savings.
- Open the page in a regular browser tab and visually confirm images are sharp, correct in color, and have no broken-image icons.
Common Mistakes to Avoid
- Serving AVIF with no fallback. A share of users will see a broken image. Always include the JPG
<img>. - Assuming AVIF is always smaller. Very small or already-optimized JPGs, and flat illustrations, can produce a larger AVIF. Measure before publishing.
- Converting already-tiny JPGs. If a JPG is already well-optimized and small, the AVIF savings may be negligible or negative.
- Using maximum encoder effort for everything. It is slow and, past a point, can even increase file size with no visible quality gain. Pick a balanced preset.
- Forgetting
width/height. Replacing JPG with AVIF without reserving box space invites layout shift. - Throwing away the JPG master. AVIF tooling is still maturing; keep an editable JPG or PNG for print, email, and future re-export.
- Assuming metadata and color survive. Verify ICC and EXIF on anything where color fidelity or rights metadata matters.
FAQ
Is AVIF smaller than JPG?
Often yes, but not always. In many benchmarks, AVIF files are roughly 40–50% smaller than JPG at comparable visual quality, and 20–30% smaller than WebP. Exact savings depend on image content, resolution, and the quality/effort settings you choose. Very small JPGs, already-optimized images, and flat illustrations may shrink only marginally — or the AVIF can end up larger. Always compare sizes after conversion.
Do all browsers support AVIF?
Most modern browsers do — Chrome 85+, Firefox 93+, Opera 71+, Edge 121+, and Safari 16.4+ (full support; Safari 16.1–16.3 has partial support only). Global coverage is approximately 93–94% per Can I Use, but you still need a JPG or WebP fallback for older browsers, some in-app webviews, and many email and OS apps. Check caniuse.com/avif for current figures, as support continues to expand.
Should I convert every JPG to AVIF?
No. AVIF is best for large photographic web images where file size and LCP matter. Keep JPG for email, print, legacy apps, and social uploads, and as the universal fallback inside <picture>. For very simple logos and flat illustrations, WebP or PNG is often a better choice.
Does converting JPG to AVIF lose quality?
Converting is a lossy-to-lossy transcode, so a low-quality JPG will carry its artifacts into the AVIF. Start from a high-quality master for the best results. At matched visual quality, a well-encoded AVIF from a good source is indistinguishable from the JPG to most viewers — at a fraction of the size.
Can converting JPG to AVIF make the file larger?
Yes. Very small JPGs, already-optimized images, flat illustrations, and incorrect quality settings can all produce an AVIF that is larger than the source JPG. This is why you should always compare file sizes after conversion and publish whichever format is actually smaller.
Should I use AVIF or WebP?
Use AVIF when maximum compression on photographic content is the priority and you can serve a fallback. Use WebP when encoding speed matters more, when you want slightly broader compatibility, or when the image is a simple logo or flat graphic where WebP often wins on file size. For most modern web workflows, AVIF + WebP + JPG in a <picture> element gives you the best of all three.
Can I open and edit AVIF files everywhere?
Support varies by application and OS version. Recent versions of Photoshop and GIMP have added AVIF support, and many modern CMS platforms handle it. However, support is not universal — verify before using AVIF for print, email, or archive workflows, since older desktop apps, some Android gallery apps, email clients, and photo printers may not handle AVIF. Keep an editable JPG or PNG master for any workflow that may need those formats.
Next Steps
- Audit your largest images first. Find the top 10–20 images by byte size (hero, product, gallery) — these give the biggest payoff for an AVIF conversion.
- Set up
<picture>with fallback on one template, measure LCP before and after, then roll out. - Compare sizes before committing. Confirm each AVIF is actually smaller than its JPG counterpart; keep whichever is smaller.
- Add a local compression pass with a no-upload tool such as LessMB so the AVIF and its JPG fallback are both squeezed as small as possible on-device, without sending originals to a server.
- Automate the pipeline with a CDN or build-step encoder so future uploads convert automatically.
- Re-measure Core Web Vitals after rollout and keep the JPG masters for anything that may need print or email later.
Sources
- Can I Use — AVIF image format browser support: caniuse.com/avif
- MDN Web Docs — Image file type and format guide: developer.mozilla.org
- AOMedia — AV1 Image File Format (AVIF) specification: aomediacodec.github.io/av1-avif
- Cloudinary — Contemplating Codec Comparisons: cloudinary.com/blog