BlogImage Compression

How to Compress AVIF Images: When It Helps and When It Doesn't

Learn how to compress AVIF images safely, when recompression helps, which quality settings to test, and when WebP, PNG, or JPEG is better.

June 10, 2026

Updated: June 10, 2026

Compress AVIF by resizing first, then re-encoding at tested quality settings. This approach helps most on large photographic images, product photos, and hero images where bandwidth affects load speed.

AVIF compression does not help much when the file is already optimized, when the image is tiny, when sharp text or UI edges must stay crisp, or when the real problem is image dimensions, loading priority, or layout—not the file format itself. The safest workflow is to test AVIF compression against the original, compare visual quality at the actual display size, and keep WebP or JPEG fallbacks when your audience or tooling needs them.

Key Takeaways

AVIF can reduce file size significantly, but recompressing an already compressed AVIF is not automatically beneficial.
The best AVIF candidates are large photos, product images, hero banners, and pages where image bytes affect LCP or mobile bandwidth.
AVIF is less reliable for screenshots, small icons, sharp text, diagrams, and assets that need pixel-perfect edges.
Always compare output visually and by file size; do not choose AVIF quality settings blindly.
Use AVIF as part of an image workflow: resize first, encode second, test in the browser, then keep fallbacks where appropriate.

What Does It Mean to Compress an AVIF Image?

An AVIF file is already a compressed image. "Compressing AVIF" usually means one of five things:

Re-encoding the AVIF at a lower quality.
Resizing the image to smaller pixel dimensions.
Removing metadata that is not needed on the web.
Changing encoder settings such as speed, quantizer, chroma subsampling, or alpha quality.
Converting from another format, such as JPEG or PNG, into AVIF.

The most important point: format conversion is not the same as optimization. A 4000 px wide product photo converted to AVIF may still be wasteful if it is displayed at 900 px. Resize first, then encode.

When AVIF Compression Helps Most

AVIF is especially useful when the image has photographic detail, gradients, natural textures, or many colors. According to MDN's image format guide, AVIF offers much better compression than PNG or JPEG and supports features such as transparency, higher color depths, and animation. Web.dev's AVIF guide (last updated 2021, still relevant for encoder parameters and compression benchmarks) notes that AVIF can provide significant savings over JPEG and WebP, though the exact savings depend on the image, settings, and quality target.

Use AVIF compression when the goal is to reduce transferred bytes while keeping the image visually acceptable.

Image type	Does AVIF compression usually help?	Why
Hero photos	Yes	Large dimensions and photographic detail usually compress well.
Product photos	Yes	AVIF can preserve useful detail at smaller sizes if settings are tested.
Blog images	Often	Good fit for photos and illustrations without tiny text.
Background images	Often	Slight quality loss may be acceptable when the image is decorative.
Transparent product cutouts	Sometimes	AVIF supports alpha, but settings must preserve edges.
Screenshots with text	Sometimes not	Text and UI edges can blur or show artifacts.
Logos and icons	Usually no	SVG, optimized PNG, or WebP may be better depending on the asset.
Tiny thumbnails	Depends	Header overhead and decode cost can reduce the benefit.
Already optimized AVIF	Usually little	Re-encoding may save very little or reduce quality.

When Compressing AVIF Does Not Help

AVIF compression is not a magic "make every image smaller" button. It can fail, or even make the user experience worse, in several cases.

The AVIF Is Already Near Its Practical Limit

If an AVIF has already been encoded with sensible settings, recompressing it may produce tiny savings with visible quality loss. This is similar to repeatedly saving a JPEG: every lossy generation can introduce more damage, because each lossy generation starts from less image information.

If you do not have the original source image, be conservative. Recompressing from a lossy AVIF gives the encoder less clean information to work with.

The Image Has Sharp Text or Interface Details

Screenshots, app UI images, code snippets, diagrams, and graphics with thin lines need crisp edges. AVIF can still work, but aggressive compression may create blur, ringing, or color bleeding around text.

For these assets, compare AVIF against PNG, lossless WebP, and sometimes SVG. Do not assume the smallest file is the best file.

The Image Is Too Small to Matter

As a rough prioritization example: a 3 KB icon or 8 KB thumbnail is rarely your performance bottleneck. If you spend time shaving 1 KB from small assets while your page has a 600 KB hero image, you are optimizing in the wrong order.

Prioritize the largest above-the-fold images, repeated product images, and pages with many images.

The Real Problem Is Dimensions

If a 2400 px image is displayed at 600 px, AVIF compression is only part of the fix. The better solution is to generate a correctly sized image and use responsive image markup.

A smaller AVIF at the wrong dimensions is still wasteful.

The Page Needs Better Loading Strategy, Not Just Smaller Files

Compressing AVIF can help page speed, but it does not replace good image delivery. You may still need:

Correct width and height attributes to prevent layout shift.
srcset and sizes for responsive images.
Lazy loading for non-critical images.
High priority loading for the LCP image when appropriate.
A CDN or caching strategy for repeated assets.

How to Compress an AVIF Image Step by Step

Use this workflow when deciding whether to compress, re-encode, or keep an AVIF image as-is.

1. Start From the Best Source You Have

If possible, encode AVIF from the original PNG, TIFF, high-quality JPEG, or design export—not from an already compressed AVIF. Each lossy generation starts from less image information, compounding artifacts.

Best source order:

Original design or raw image export.
High-quality PNG or TIFF.
High-quality JPEG.
Existing WebP.
Existing AVIF only if no better source exists.

2. Resize Before You Compress

Decide where the image will appear and what pixel sizes are actually needed.

Use case	Typical output approach
Full-width hero image	Generate multiple widths, such as 768, 1280, 1600, and 2000 px.
Blog inline image	Generate widths close to the content column and high-DPR variants.
Product gallery	Generate thumbnails, medium previews, and zoom images separately.
Decorative background	Compress more aggressively if fine detail is not important.
Social image	Use the platform's recommended dimensions instead of oversized exports.

If the image will never display wider than 900 px, a 3000 px AVIF is usually unnecessary.

3. Encode Multiple Versions: avifenc Commands

For command-line workflows, avifenc (from the libavif project) is a widely used encoder. The cq-level flag controls quantization: lower values mean higher quality and larger files; higher values mean stronger compression and smaller files. The --speed flag controls encoder speed: higher speed values are faster but may reduce compression efficiency or quality.

Example commands:

High quality — for important product or hero images:

avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 --speed 4 input.png output.avif

Balanced — for standard web photos:

avifenc --min 0 --max 63 -a end-usage=q -a cq-level=28 --speed 6 input.jpg output.avif

Aggressive — for decorative or low-priority images:

avifenc --min 0 --max 63 -a end-usage=q -a cq-level=40 --speed 8 input.jpg output.avif

avifenc key parameters:

Parameter	Effect	Guidance
`-a cq-level`	Quantizer level (0 = lossless, 63 = max compression)	Start at 26–32 for standard photos; 18–24 for high-detail images
`--speed`	Encoder speed (0 = slowest/best quality, 10 = fastest)	4–6 is a practical balance for production
`--min / --max`	Quantizer bounds	Use `--min 0 --max 63` to let `cq-level` control quality
`-a end-usage=q`	Constant quality rate control	Recommended for web image encoding
`--jobs`	Parallel encoding threads	Set to available CPU cores for faster batch encoding

You do not need to expose this complexity to end users. The point is to compare candidates before publishing.

4. Browser-Based Workflow for One-Off Files

If you need to test whether compression actually reduces your specific AVIF before changing a build pipeline, a browser-based tool is faster than setting up a CLI. LessMB is useful for one-off checks: upload your image locally, compare the compressed file size, and download the result—all processed in the browser without sending files to a server. Use the CLI approach for automated production workflows.

5. Compare at the Real Display Size

Do not judge only by zooming into the original at 300%. Users see the image at its rendered size on a phone, laptop, or high-DPR display.

Check for:

Banding in gradients.
Blurry text or UI labels.
Ringing around edges.
Plastic-looking skin or product texture.
Color shifts.
Damaged transparency edges.
Loss of important detail in shadows or highlights.

6. Measure File Size and Page Impact

A smaller file is useful only if it improves the page or user experience.

Track:

Original file size.
Compressed AVIF file size.
Percent reduction.
Visual acceptability.
Browser rendering.
LCP impact for above-the-fold images.
Total page weight for image-heavy pages.

For a single image, a 15 KB saving may not matter. Across a catalog, gallery, or blog archive, the same percentage reduction can become meaningful.

How Much Smaller Can AVIF Get?

There is no universal percentage. Claims like "AVIF is 50% smaller" are useful as directional benchmarks, not promises. MDN cites examples where lossy AVIF images can be around 50% smaller than JPEG images, and web.dev's 2021 encoder guide reports greater than 50% savings versus JPEG in some tested cases. Results depend heavily on image content, encoder implementation, and quality target—not on the format alone.

Your result depends on:

Source format and source quality.
Image content.
Target dimensions.
Encoder implementation.
Lossy vs lossless mode.
Quality settings.
Transparency.
Whether the image has text, gradients, or fine patterns.
How closely users inspect the image.

Instead of asking "How much should AVIF save?" ask "What is the smallest version that still looks right in context?"

AVIF vs WebP vs JPEG vs PNG

AVIF is often excellent, but it is not always the default answer. MDN describes WebP as an excellent choice for images and animated images, while noting that AVIF offers slightly better compression. Regarding progressive rendering: AVIF does not behave like progressive JPEG in common browser delivery workflows. Even though AVIF has scalability features in its spec, teams should test perceived loading behavior for large hero images in their actual deployment environment. Can I Use provides current browser support data for AVIF—worth checking if your audience includes older browsers or embedded webviews (global support was approximately 93% as of early 2026, but verify before publishing).

Format	Best for	Strengths	Weaknesses	Use instead when
AVIF	Photos, large web images, bandwidth-sensitive pages	Strong compression, transparency support, modern features	Slower encoding, quality tuning needed, fallback may be needed	Already optimized files, older browsers without fallback
WebP	General web images, broad modern support	Good compression, good tooling, animation and transparency	Often larger than AVIF at similar quality	You need broad compatibility with minimal tooling overhead
JPEG	Photos and legacy compatibility	Universal support, fast decode, simple workflow	No transparency, weaker compression than modern formats	Maximum compatibility required, or fast delivery to old environments
PNG	UI, screenshots, lossless graphics	Crisp edges, transparency, lossless	Large for photos	Sharp text, UI elements, diagrams, or icons needing exact pixel fidelity
SVG	Logos, icons, diagrams	Resolution-independent, often tiny	Not for photos or complex raster images	Any vector-origin asset: logos, icons, or simple diagrams

A good production strategy is not "AVIF everywhere." It is "best format for this image, this quality target, and this audience."

Recommended Decision Framework

Use this table before compressing AVIF files in bulk.

Question	If yes	If no
Is the image large enough to affect page weight?	Test AVIF compression.	Leave it unless many small images add up.
Is it photographic or texture-rich?	AVIF is a strong candidate.	Compare with PNG, WebP, or SVG.
Is there sharp text or UI detail?	Use conservative settings and compare carefully.	More compression may be acceptable.
Do you have the original source?	Encode from the original.	Avoid aggressive recompression.
Is this the LCP image?	Test file size and load priority together.	Lazy loading may matter more.
Does your audience support AVIF?	Serve AVIF directly or through content negotiation.	Use fallbacks with WebP/JPEG/PNG.
Is quality more important than bytes?	Use higher quality or another format.	Try stronger compression.

Common AVIF Compression Mistakes

Compressing Without Resizing

The most common mistake is keeping huge dimensions and only changing format. A correctly resized JPEG or WebP can beat an oversized AVIF in real page performance.

Comparing File Size Without Comparing Quality

If one version is much smaller but visibly worse, it is not an equivalent comparison. Always compare at similar perceived quality.

Using One Quality Setting for Every Image

A landscape photo, a product photo, a screenshot, and a transparent icon do not need the same settings. Batch defaults are convenient, but sample testing is essential.

Forgetting Fallbacks

Modern AVIF support is strong, but not universal in every browser, app, CMS preview, email client, or social scraper. If the image is business-critical, make sure unsupported environments get a usable fallback. For HTML, use a <picture> element in a code block like this:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description" width="800" height="600">
</picture>

Recompressing Lossy Files Repeatedly

Repeated lossy compression compounds artifacts. Keep originals and regenerate derivatives when you need new sizes or settings.

Verification Checklist Before Publishing

Before replacing images with compressed AVIF versions, verify the result.

Practical Next Steps

If you are optimizing one image, start simple:

Check the displayed dimensions.
Resize the source image to the largest size actually needed.
Export two or three AVIF versions at different cq-level values.
Compare file size and visual quality at the actual display size.
Keep the smallest acceptable version.
Test it in the page, not only in your file browser.

If you are optimizing many images, build a repeatable workflow:

Segment images by type: photos, screenshots, icons, product images, backgrounds.
Pick test samples from each group.
Compare AVIF, WebP, JPEG, PNG, and SVG where relevant.
Define quality settings by image type, not globally.
Automate responsive sizes.
Monitor page weight and Core Web Vitals after rollout.

A simple rule works well: use AVIF when it provides meaningful byte savings at acceptable quality, but do not force it when another format is clearer, smaller, safer, or easier to support.

FAQ

Can AVIF images be compressed further?

Yes. You can re-encode an AVIF with stronger lossy settings, resize it, remove metadata, adjust alpha quality, or change encoder options. However, if the AVIF is already optimized, additional compression may save little and introduce visible artifacts.

Can you compress AVIF without losing quality?

Only by removing metadata or using lossless mode. Any lossy re-encoding introduces some degradation. The practical approach is to find the lowest cq-level that still looks acceptable at the real display size, then stop there.

What AVIF quality setting should I start with?

For avifenc, start with cq-level 28 for standard web photos and cq-level 18–22 for high-detail product or hero images. Lower values give higher quality; higher values give smaller files. Always compare the output visually before publishing.

Is AVIF better than WebP?

Often, but not always. AVIF usually has stronger compression for photographic images, while WebP has excellent tooling and broad modern support. The better choice is the one that produces the smallest acceptable image for your actual use case.

Should I use lossless AVIF?

Use lossless AVIF only when you truly need lossless reproduction and it beats alternatives in file size. For many web photos, lossy AVIF gives much better size savings with no obvious visual difference at normal display sizes.

Why did my AVIF file get bigger after compression?

This can happen if the source was already highly optimized, if the encoder settings are too conservative, if metadata is preserved, if lossless mode is used, or if the image content is not well suited to AVIF. Compare against WebP, PNG, or JPEG before assuming AVIF is the right output.

Does AVIF support transparency?

Yes. AVIF supports transparency, which makes it useful for some product images and cutouts. Transparent edges should be checked carefully because aggressive compression can create halos or rough edges around alpha channels.

Do I still need JPEG or WebP fallbacks?

Often yes, especially if your audience includes older browsers, embedded webviews, CMS previews, or environments that may not handle AVIF consistently. The safest web implementation serves AVIF first and falls back to WebP or JPEG where needed.

Can AVIF compression hurt SEO?

Indirectly, yes, if it creates poor visual quality, broken images, unsupported delivery, or slower rendering from a bad implementation. It can help SEO when it improves user experience, load speed, and image delivery without damaging content quality.