WebP and AVIF Quality Settings: Which Numbers Should You Actually Use?

Converting images to WebP or AVIF is easy. Choosing the quality number is where people stall. Should it be 75 or 90? Is AVIF quality 50 the same as JPEG quality 50? Why does the same slider value give very different file sizes in different tools? The honest answer is that quality values are not universal units. They are encoder-specific dials that map to internal parameters, and the numbers mean different things in WebP, AVIF and JPEG. This guide explains how the scales differ, offers sensible starting values by image type, covers the speed settings that matter for AVIF and shows how to compare results fairly so you can choose settings with evidence instead of folklore.

Why quality numbers are not comparable

A JPEG quality of 80 controls the quantization tables used during compression. A WebP quality of 80 controls a different set of parameters inside the VP8 based encoder. An AVIF quality of 80 maps to quantizer settings in the AV1 encoder, and some command-line tools express AVIF on a reversed scale where lower numbers mean higher quality. Because the internals differ, the same number produces different visual results and file sizes across formats and even across tools that wrap the same encoder.

This is why advice like "use quality 80 everywhere" gives uneven results. The right approach is to pick a target appearance and find the number that achieves it in each format.

WebP basics

WebP offers lossy and lossless modes. Lossy WebP uses a quality value from 0 to 100, where higher means better quality and a larger file. Lossless WebP preserves every pixel and is controlled by an effort setting rather than a quality percentage. WebP also supports transparency in both modes, which makes lossy WebP with alpha a strong replacement for PNG on photographic artwork with transparent edges.

AVIF basics

AVIF is based on the AV1 video codec. It typically reaches smaller files than WebP and JPEG at comparable visual quality, especially at lower bitrates, and it supports transparency, high bit depth and wide color. The price is slower encoding and, in some tools, more settings to understand.

Scales differ by tool. Many image libraries and graphical converters present AVIF quality as 0 to 100, where higher is better. The reference command-line encoder avifenc has historically exposed quantizer values from 0 to 63 where lower means better quality, plus a newer quality option on a 0 to 100 scale in recent versions. Check your tool's documentation to see which scale it uses before you copy a number from a blog post.

Encoder speed and effort

AVIF encoders let you trade time for compression. A slow setting searches more options and produces smaller files, while a fast setting finishes quickly with a larger result. In avifenc this is the speed option, typically a number from 0 for slowest and best to 10 for fastest. For a build pipeline that encodes thousands of images, a mid-range speed is usually the practical compromise. For a handful of hero images that are encoded once, a slower setting is worth the wait.

WebP has a similar idea called method or effort, usually 0 to 6, where higher means slower and slightly smaller. The difference is much smaller than in AVIF, so most people leave it at the default or raise it for final exports.

Chroma subsampling and bit depth

Both formats can store color at reduced resolution. Subsampling saves bytes and is rarely visible on photographs, but it can blur the edges of saturated colored text or thin colored lines. If you see color fringing on interface graphics, choose full chroma resolution, accepting a larger file, or use lossless. AVIF also supports 10-bit color, which can reduce banding in smooth gradients and is useful for HDR workflows, at the cost of larger files and less universal support in tools.

A fair way to compare settings

1. Pick three to five representative images: a photograph with skin or sky, a product shot, a graphic with text and one with gradients.
2. Encode each at three quality values per format, for example WebP 70, 80 and 90, and AVIF 55, 65 and 75.
3. Record file sizes in a simple table.
4. View originals and outputs at 100 percent zoom in the same viewer. Do not judge from thumbnails or fit-to-window.
5. Flip between original and output quickly. Banding, blocking and smeared detail are easier to spot this way.
6. Choose the lowest quality that you cannot distinguish from the original in normal viewing conditions.
7. Apply the settings to a larger sample before adopting them as defaults.

If you want a numeric check, compute an image quality metric such as SSIM or a perceptual metric between original and output. Metrics are helpful for regression testing in pipelines, but human viewing remains the final judge, because metrics do not always agree with perception.

Source quality matters

Encoding a heavily compressed JPEG into WebP or AVIF does not remove its existing artifacts. It encodes them, sometimes making blocky areas worse. Always start from the best source you have, ideally the original export, rather than a previously compressed derivative. Also resize before you encode: reducing pixel dimensions to the display size is the biggest saving available, and it is independent of format.

Transparency

If you have PNGs with transparency, you have several routes. Lossless WebP preserves every pixel and is often smaller than the PNG. Lossy WebP with alpha can be much smaller for photographic cutouts. AVIF supports alpha and can be smaller still. Test with the image on both light and dark backgrounds, because halos at edges are the typical failure mode.

Browser support and fallbacks

WebP is supported across modern browsers. AVIF support has become broad in current versions of major browsers, but you should confirm against current compatibility data for the audience you serve. A safe pattern uses the picture element with AVIF first, WebP second and a JPEG or PNG fallback.

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Product overview" width="1200" height="800" />
</picture>

Frameworks such as Next.js can generate and negotiate formats for you. Our guide to best image formats for websites explains when each choice fits.

Batch conversion locally

Converting a whole asset library by hand is tedious, and uploading it to a web converter is not an option for private material. TinyPixels converts PNG and JPEG to WebP and AVIF on your own Mac or Windows PC, processes folders in parallel and offers web, balanced and maximum presets so you do not have to pick a number for every job. It runs offline, and Pro is a one-time purchase rather than a subscription. You can still override settings per batch when you want to run the comparison described above.

Settings cheat sheet

Common mistakes

• Copying a quality number from another tool without checking its scale.
• Judging quality from thumbnails.
• Converting already compressed JPEGs and expecting miracles.
• Using lossy settings for text-heavy screenshots.
• Using the slowest AVIF setting for thousands of images in a build.
• Skipping the fallback for audiences on older software.

Worked example: choosing settings for a product page

Imagine an online shop with a product page that has one large hero photograph, six gallery images and a set of small thumbnails. Rather than picking one global number, treat each group separately. For the hero, the image is large and visible, so use a slower AVIF setting once and a conservative quality, then check skin tones, textures and smooth backgrounds for banding. For the gallery, which people zoom into, start slightly higher in quality and compare at 100 percent. For the thumbnails, which display tiny, a lower quality value is usually invisible and the savings multiply across a category page with dozens of items.

Record the chosen values in a small table in your repository so everyone applies the same settings. Review them when you change the design, because a new layout that shows images larger can expose artifacts that the old, smaller layout hid.

When not to convert

Converting is not always the right move. If a JPEG is already well compressed and small, converting it to WebP or AVIF may save little and costs you another lossy generation. If your audience includes old software that cannot display the new formats and you do not want to maintain fallbacks, a good JPEG is perfectly fine. Likewise, tiny icons are often better as SVG, and pixel-exact sprites may be best as lossless PNG or lossless WebP. Convert where it brings clear savings, and leave alone what is already efficient.

Automating the pipeline

Manual conversion works until it does not. For a site with frequent image changes, build conversion into your process: export originals to a source folder, convert with fixed settings into the folder your site serves, and commit both the settings and the outputs. A watch folder or a build step keeps the outputs in sync, and a short checklist in the pull request template reminds contributors to run it. Whatever automation you choose, keep the original masters somewhere safe, because you will want to re-encode from them when encoders improve or your quality targets change.

Conclusion

There is no magic number. Start around 75 to 80 for WebP and 60 to 70 for AVIF on a 0 to 100 scale, use lossless for text-heavy graphics, resize before you encode and compare outputs at full size on your own images. A short experiment on five representative files beats any rule of thumb, and a local batch tool lets you apply what you learn to the whole library without uploading anything.

Frequently asked questions