WebP Quality Settings: Lossless Beat q90 on 341 Cards

Every cover image on this blog passes through one line of Python: img.save(buf, format="WEBP", quality=82, method=6). The comment above it in make-thumbnails.py, written in Korean, says quality 82 shows no noticeable loss on this kind of graphic and stays under 100 KB. A second script that handles product photos copied the number, with a comment calling it the same standard as the thumbnails. Nobody ever measured it. So I re-rendered all 341 cards on the site and encoded each one 31 ways. The finding that changes the advice: on these cards, every lossy setting above 85 produced a bigger file than lossless WebP, and quality 100 came out 1.73 times the lossless size. On photos the result reversed.

What the quality number controls

The WebP quality value means different things depending on the mode. In Pillow's documentation it is "Integer, 0-100, defaults to 80. For lossy, 0 gives the smallest size and 100 the largest. For lossless, this parameter is the amount of effort put into the compression." method is a separate speed/size trade-off from 0 to 6 that defaults to 4. Google's cwebp reference uses a different default, -q 75, so the same image comes out at two different sizes depending on which tool wrote it.

The part that trips people up is that quality=100 is still lossy. It keeps the 4:2:0 chroma subsampling of the lossy format and spends a lot of bits trying to approximate an image it will never reproduce exactly. lossless=True is a different encoder entirely.

The sweep

The stored thumbnails are already quality-82 WebP, and re-encoding them would stack a second loss on the first. So I imported make_card() from the production script, redrew all 341 published titles to lossless RGB, and encoded each card with Pillow 12.3.0 (libwebp 1.6.0) at 15 lossy qualities, 7 methods, Pillow's defaults, lossless at two effort levels, optimized PNG, and AVIF at five qualities. For every file I decoded the bytes and scored SSIM, PSNR and the largest per-channel pixel error against the source. For contrast I ran the same matrix on four public-domain and CC0 photographs that ship with scikit-image. The machine is the M4 Mac mini that publishes this site.

Cards: lossless ties lossy at quality 85

The ratios are medians of per-card ratios, not ratios of the medians. Lossless beat our quality-82 files on only 1 of 341 cards, and it cost a median 6.7% more bytes, never more than 14.2%. At quality 85 the two were even: lossy was smaller on 122 cards and bigger on the other 219. At 90 and 95 lossy was bigger on all 341. Above 85 you are paying extra bytes to keep an approximation when the exact picture is cheaper.

The loss has a specific location. I sampled every 40th card and found the pixel with the largest error. It was never in the background gradient. It sat on the edge of a thin colored element, usually the small category label: a blue pixel of (96, 165, 250) came back as (124, 152, 190), and on the amber "experiments" label the worst channel was off by 107 out of 255. Between 1.1% and 2.6% of each card's pixels were off by 20 or more on some channel. That is 4:2:0 chroma subsampling blurring thin, saturated text, the same failure people recommend -sharp_yuv for. At 2× zoom I could not tell quality 82 from the source by eye. At quality 10 the blue label had visible colored fringes.

Photos: the opposite answer

On the four photographs, lossless WebP was 9.4 times the size of quality 82 (8.5 to 10.4 times, median 291 KB against 28 KB). Quality 100 was about a third of the lossless size, and PNG was larger still at 362 KB median. Photographic noise has no flat regions for the lossless predictor to exploit, so "above 85, just go lossless" is advice for graphics and screenshots, not photos. One caveat: the scikit-image photos are small (up to 512×512) and were JPEG files before the library shipped them, so they are softer than a fresh camera frame. The photographer Aurélien Pierre's complaint about WebP concerns that material. He found posterized rings in smooth backgrounds at quality 80 through 96, and the 393-comment Hacker News thread on it splits between people who see the banding immediately and people who never notice it.

Method, effort and the knobs Pillow hides

Holding quality at 82, method 0 produced 30,068 B and method 6 produced 21,798 B, with SSIM flat between 0.9914 and 0.9917. Most of the saving arrives by method 3 (22,192 B). In a serial timing run on 20 cards, method 6 took 28.5 ms per card and method 4 took 20.5 ms. Lossless at effort 50 took 13.5 ms, faster than our lossy setting. Lossless at effort 100 took 827 ms per card, about 60 times as long, and in that 20-card sample it came out a median 2.0% larger than quality 82 and smaller on 5 cards.

Pillow's WebP writer reads lossless, quality, alpha_quality, method, exact and metadata, and nothing else. I checked the installed WebPImagePlugin.py. There is no switch for sharp_yuv, presets or near-lossless, so I ran those through cwebp on every eighth card (43 cards):

cwebp -q 82 -m 6              21,866 B  PSNR 38.8 dB  37 ms
cwebp -q 82 -m 6 -sharp_yuv   22,324 B  PSNR 40.1 dB  64 ms
cwebp -preset text -q 82      23,050 B  PSNR 38.9 dB
cwebp -near_lossless 60       22,414 B  max error 2/255
cwebp -z 9                    22,538 B  exact, 968 ms

-sharp_yuv bought 1.3 dB of PSNR for 2% more bytes and 70% more encode time, which is close to Ctrl blog's 68% figure. It did not fix the label edges: the median worst-pixel error went from 60 to 59. The text and drawing presets made files bigger with no gain. Near-lossless at 60 landed within 0.2% of true lossless while allowing each channel to drift by at most 2. On this material there was no point accepting that drift.

AVIF, which Pillow 12 also writes, was 23% smaller than WebP quality 82 at its own quality 80, with higher SSIM (0.9940). It took about 85 ms per card. The two formats' quality scales are unrelated, so compare AVIF and WebP files by size and score, not by the number you passed in.

What I would set, by content type

• Flat graphics, cards, screenshots with text: lossless=True, quality=50. It is pixel-exact, about 7% heavier than quality 82 and faster to encode. If you want lossy anyway, stay at or below 80, because above 85 lossless wins on size too.
• Photos: lossy between 75 and 85. On the four photos, Pillow's default (80, method 4) made files about 3% smaller than quality 82 at method 6. Never use lossless for web delivery.
• Mixed, or unknown ahead of time: encode both and keep the smaller. At 13.5 ms for the lossless pass, the second encode is cheap.

I have not changed make-thumbnails.py in this run. Flipping it would change 341 image files, and the result I would be trading 1.6 KB per card for is exactness on a label nobody has complained about. The code comment was half right. Quality 82 does stay far under 100 KB (the largest card was 24.9 KB) and does look clean. It was not the smallest option for the quality it delivers, and above 85 it would have been the worst one. Where these files end up, and what that costs, is covered in generating OG images with Python Pillow, why an og:image does not show, and the Supabase Storage header that hid them from search.

Questions

What is the best WebP quality setting?

It depends on the content. For photos, 75 to 85 lossy is the usual range, and Pillow defaults to 80. For flat graphics and text, lossless WebP often matches lossy 85 in size. On 341 blog cover cards, every lossy setting above 85 made larger files than lossless.

Is WebP quality 100 lossless?

No. Quality 100 is still the lossy encoder with chroma subsampling. On 341 text-heavy cards it averaged 1.73 times the size of true lossless WebP and still changed pixels. Use lossless=True in Pillow or -lossless in cwebp for exact output.

What does quality mean for lossless WebP in Pillow?

It sets compression effort, not fidelity. The output is exact at any value. In our test, effort 0 produced files 13% larger than effort 50, and effort 100 took about 60 times longer than effort 50 per card.

Update, 2026-09-18. The HTML around these cards got the same treatment. Brotli quality 11 would make the 344 pages 18% smaller than gzip, but Cloudflare serves quality 4, and I kept it. The numbers are in brotli vs gzip.

Measured on 2026-09-18 on an M4 Mac mini running macOS 26.4.1, with Pillow 12.3.0, libwebp 1.6.0, cwebp 1.6.0 and scikit-image 0.26.0. SSIM is computed on RGB, and all sizes are medians. The 341 cards were redrawn from the production make_card() function, not taken from the stored files. The full 31-setting run used 8 worker processes, so its timings are not reported here. All timings come from a separate single-process run on 20 cards, and the cwebp rows from every eighth card (43). The four photos are scikit-image's astronaut (NASA, public domain), coffee and chelsea (CC0) and rocket (SpaceX, public domain). The error-location analysis sampled 9 cards. Pillow's option list comes from the installed plugin source, not only the docs. The banding claims about photographs are the linked author's and commenters' findings, not mine. The Playbook link is our own product.