WebP Quality Settings: How to Choose the Right Quality Factor for Every Image Type

The quality factor is the single biggest lever when converting JPG to WebP. Set it too low and you see visible artefacts. Set it too high and you lose most of the file-size benefit. Most people just pick 80 and move on — but knowing what actually happens across the quality spectrum lets you make smarter decisions per image type.

This guide covers how the WebP quality scale actually works under the hood, what each level gives you in practice, and exactly which setting to use for product photos, hero banners, thumbnails, UI screenshots, and everything in between.

What Does the WebP Quality Factor Actually Control?

The WebP quality scale runs from 0 to 100. The most important thing to understand is that this scale is not linear. The relationship between quality number and file size is highly non-linear, with dramatic differences at the high end:

• Going from quality 90 to 100 increases file size by approximately 3× — a massive jump for nearly imperceptible visual gain
• Going from quality 75 to 80 increases file size by approximately 20% — a moderate step with visible improvement on detailed edges
• Going from quality 60 to 70 increases file size by approximately 15% with a more noticeable quality jump

Under the hood, the quality number controls the tradeoff between VP8 prediction residual quantization and entropy coding. WebP encodes each image block by predicting its content from neighbouring blocks, then storing only the difference (the residual). A lower quality setting applies heavier quantization to those residuals — more data is rounded off and thrown away, producing a smaller file but introducing blocking artefacts. A higher quality setting retains more of that residual information, producing a cleaner image at the cost of a larger file.

One critical point many people miss: quality 100 is not lossless. It is the highest lossy setting, but WebP still discards some information. For true lossless encoding — where every pixel is reproduced exactly — you must use the -lossless flag. When -lossless is active, the quality number is ignored entirely.

The Quality Spectrum: What Each Level Gives You

The table below shows typical results for a photographic image encoded from a high-quality source. File size comparisons are relative to the same image encoded as JPEG at quality 80 (the standard web JPEG setting).

The highlighted rows (80–85) represent the practical sweet spot for most photography. Notice how quality 100 still produces a file that is 90% the size of a JPEG — you get almost none of WebP's compression advantage at that extreme setting. The real gains arrive in the 75–85 range.

Lossy vs Lossless WebP — Which Mode Should You Choose?

The quality number only applies to lossy WebP, which is the default mode. There is also a completely separate lossless mode that works differently:

The most common mistake is using lossy WebP for UI screenshots and icons. When you compress a screenshot with lossy WebP at quality 80, ringing artefacts appear around text edges — the kind of subtle blurriness that makes an interface look unpolished. Lossless WebP eliminates this completely, and for screenshots the file size is usually acceptable since they contain large flat-colour regions that compress well.

Quality by Image Type: Practical Recommendations

The right quality setting depends heavily on how the image will be displayed and how closely it will be scrutinised. Here are specific recommendations for the most common image types on the web.

Product Photos

E-commerce product images live in a tension between quality (customers need to see the product clearly) and performance (pages with many products need to load fast).

• Main product images (large, single product view): quality 85 — no visible quality loss compared to the source JPEG, but files are significantly smaller
• Product thumbnails in grids (displayed at 200–300px): quality 78–80 — artefacts are invisible at thumbnail sizes, and you save meaningful bandwidth when loading 20–40 products on a category page
• Zoom / detail views (user has clicked to inspect closely): quality 88–90 — the user is actively scrutinising at this point; quality matters more than file size

Hero / Banner Images

Hero images are typically the LCP (Largest Contentful Paint) element — the single image Google measures when evaluating your Core Web Vitals. Getting this one image right has the biggest impact on both performance scores and SEO.

• Full-width desktop heroes (1200px+): quality 82–85 — balances visual quality with file size for the image that most affects LCP
• Mobile heroes (displayed smaller, often served via srcset): quality 78–80 — the smaller display size masks artefacts that would be visible at desktop resolution
• Background images with text overlay: quality 70–75 — the overlaid text covers fine image detail, so you can compress more aggressively without the degradation being visible

Blog and Article Images

• Article body images: quality 80 — the standard setting works well for inline editorial photography
• Decorative / illustration images: quality 75 — these are often not closely scrutinised, so more compression is acceptable
• Author avatars and small portraits: quality 80 — faces are perceptually sensitive; maintain standard quality even at small sizes

Thumbnails and Preview Images

• Video thumbnails: quality 75–78 — usually displayed at 320×180px or smaller, so artefacts are not visible at normal viewing distances
• Gallery thumbnails: quality 72–78 — aggressive compression is acceptable since users click through to see the full image
• Social share preview images (og:image): keep as JPEG — WebP is not supported by all social media scrapers and link preview services, so JPEG is the safe choice for meta images

UI and App Screenshots

Always use lossless WebP for UI and app screenshots. Lossy compression at any quality level introduces ringing artefacts around text — that characteristic blurring on the edges of letters that makes screenshots look low-quality. The lossless mode encodes screenshots pixel-perfectly, and because screenshots contain large flat-colour regions, lossless WebP compresses them efficiently.

Why 80–85 Is the Industry Sweet Spot

Multiple independent sources converge on quality 80–85 as the optimal range for photographic content on the web:

• Google's cwebp default is quality 75 — the command-line encoder ships with 75 as the out-of-the-box setting, acknowledging that very significant compression is acceptable for web delivery
• Squoosh (Google's browser-based image optimiser) defaults to 75 for new conversions
• WordPress Performance team benchmarks identified quality 82 as optimal for the majority of photographic content — the point where file size savings are maximised without any perceptible quality degradation on typical screens
• Netflix and YouTube use quality 80–85 ranges for their WebP thumbnail generation pipelines

The numbers back this up consistently:

• File size vs quality 100: approximately 55–60% smaller at quality 82
• File size vs JPEG quality 80: approximately 30–35% smaller at WebP quality 82
• Visual difference from quality 80 to quality 90: imperceptible to 95%+ of viewers at normal viewing distances on typical screens

The takeaway is practical: unless you have a specific reason to go higher (close-up product photography with fine texture detail, for instance), quality 82 is a sensible default that maximises compression while keeping visual quality beyond any reasonable complaint.

How to Set Quality in Common Tools

Every major image processing tool supports the WebP quality setting. Here are the exact commands and options for the most common tools.

cwebp (Google's Official Encoder)

# Single file, quality 82
cwebp -q 82 photo.jpg -o photo.webp

# Batch convert all JPGs at quality 82
for f in *.jpg; do cwebp -q 82 "$f" -o "${f%.jpg}.webp"; done

# Lossless for UI elements and icons
cwebp -lossless icon.png -o icon.webp

Install cwebp via brew install webp on macOS or apt install webp on Debian/Ubuntu. The -q flag sets quality (0–100); -lossless ignores the quality value and encodes without data loss.

ImageMagick

# Convert a single file
magick convert photo.jpg -quality 82 photo.webp

# Batch convert all JPGs in a directory
magick mogrify -format webp -quality 82 *.jpg

FFmpeg

ffmpeg -i photo.jpg -q:v 82 photo.webp

Note that FFmpeg's -q:v flag maps to the same 0–100 scale as cwebp. This is useful when you are already using FFmpeg in a video processing pipeline and want to handle still images in the same workflow.

Node.js (Sharp)

const sharp = require('sharp');

// Lossy WebP at quality 82
await sharp('photo.jpg')
  .webp({ quality: 82 })
  .toFile('photo.webp');

// Lossless WebP for icons and UI elements
await sharp('icon.png')
  .webp({ lossless: true })
  .toFile('icon.webp');

// Near-lossless (very high quality lossy, useful for archiving)
await sharp('photo.jpg')
  .webp({ nearLossless: true, quality: 60 })
  .toFile('photo-near-lossless.webp');

Sharp is the most common Node.js image library. The nearLossless option applies pre-processing to group similar pixel values before encoding, reducing file size while staying very close to lossless quality — a middle ground useful for archiving high-quality sources.

Common Mistakes to Avoid

• Setting quality 100 thinking it is lossless. It is not — it is just the highest lossy setting. Quality 100 still discards some information and produces files much larger than necessary. Use -lossless when you genuinely need lossless encoding.
• Re-encoding JPEGs repeatedly at low quality. Every re-encode stacks artefacts from the previous generation on top of new ones. If you are working from a JPEG source, encode to WebP once at quality 85+ and keep that as your working file. Better yet, always encode from the original RAW or TIFF when available.
• Using the same quality for all images regardless of content. A quality 80 setting that works perfectly for a landscape photograph will look noticeably degraded on a product photo being zoomed into, and is unnecessarily high for a 160px thumbnail. Match quality to the use case.
• Using lossy WebP for UI screenshots. Lossy compression at any setting produces ringing artefacts around text and sharp edges. Screenshots and interface graphics need lossless mode for pixel-perfect results.
• Using lossless WebP for photographs. Lossless encoding of photographic content produces files that are typically larger than JPEG — sometimes significantly. Lossless is efficient for flat-colour graphics; it is wasteful for photos. Use lossy quality 80–85 for all photography.
• Ignoring the non-linear quality curve at the high end. Moving from quality 85 to 95 roughly doubles the file size for a barely perceptible visual improvement. If you are chasing the last few percent of quality, check whether your users would actually see the difference at their typical screen size and viewing distance.

Frequently Asked Questions