WebP quality: which setting to use, measured from 40 to 100

What WebP quality should I use?

Use quality 75 for photos on a website. It is cwebp’s default, and it is where libwebp’s scale turns steep. Go to 80 or 85 when the WebP replaces a JPEG saved at 80. Use 75 to 80 for screenshots. Save text, logos and flat art as lossless WebP instead.

What the WebP quality number means

The WebP quality number sets how much fine detail the encoder rounds away. It is not a percentage of the picture kept. A lower number rounds harder, so the file shrinks and the detail blurs into blocks. The dial runs from 0 to 100 in cwebp, 1 to 100 in sharp, and 0 to 1 in a browser’s canvas.

The scale is not even. libwebp’s own code maps quality in two straight lines that meet at 75, and the line above 75 is 3 times steeper. A comment in the code says why: good quality is “around q=75”, as in JPEG.

Our photo shows the bend. From quality 60 to 75 it grew 17%, from 185.6 KB to 217.8 KB. From 75 to 90 it grew 92%, to 417.8 KB. Below 75, neighbours can even make the same file: 72 and 73 both gave 211.7 KB.

WebP quality from 40 to 100, measured on 6 images

We saved 6 images at every fifth quality from 40 to 100 with Blinkimg’s engine. Two are photos: our iguana and a boat at sunset with a smooth sky. Then a screenshot, a card of text, a soft-edged logo and flat colour blocks. The table gives each file’s size.

The photos grew the most past 75. The iguana went from 217.8 KB to 815.8 KB, 3.7 times the bytes. The sunset grew 5.8 times, because its smooth sky costs little at 75 and a lot at 100. The flat art barely moved, and its lossless file was the smallest of all at 0.2 KB.

The best WebP quality for the web

For photos, start at 75. Each step above it is a big one, and each buys less detail per kilobyte than the last. On the iguana, 75 to 80 added 43.5 KB for 1.4 dB. 95 to 100 added 195.6 KB for 1.3 dB: 4.5 times the bytes for less gain.

Page weight adds up. Ten photos like ours weigh 2.2 MB at 75 and 4.2 MB at 90. Use 80 to 85 for a hero image people look at closely. Skip lossy 100: on both photos and the screenshot it made the largest file, and still not an exact one.

WebP quality vs JPEG quality

The two scales do not match. On our photos, a WebP at 80 scored the same as a JPEG at 69 to 72, not 80. To match a JPEG at 80, set WebP to about 85. We scored each file with SSIM, the measure of structure Google’s own study used.

Our result agrees with Jeff Kaufman’s 2014 test, which found WebP 80 close to JPEG 67. Twelve years of libwebp later, the gap is about the same. Malte Ubl’s 2021 table put WebP 82 next to JPEG 80, scored with a different measure, DSSIM. The measure moves the answer: by PSNR, our WebP 80 matched a JPEG at 81 on the iguana.

Is WebP 25% to 34% smaller than JPEG?

Not on our photos. Google says lossy WebP is 25% to 34% smaller at the same SSIM. That figure comes from a study of libwebp 0.1.2 from 2011 against libjpeg 6b from 1998. With today’s encoders, our photos came out 10% to 23% smaller at quality 75 to 85. The screenshot, the text and the logo came out at under half the size of the matching JPEG.

WebP lossless vs lossy

Lossless WebP keeps every pixel; lossy WebP at any quality does not. On text, logos and flat art, lossless was smaller than lossy at 85, because long runs of one colour pack tightly. On photos and screenshots, lossless was several times the size of lossy at 100.

Is WebP quality 100 lossless?

It depends on the tool. In cwebp, sharp, Pillow and Squoosh, quality 100 is still lossy. Our iguana at 100 was 815.8 KB and scored 45.1 dB, not identical. Its lossless file was 2.0 MB. ImageMagick switches to lossless at 100. So do Chrome and Firefox when a page asks a canvas for quality 1: both files we got back were lossless.

Lossy WebP also halves the colour detail at every quality, a scheme called 4:2:0. Red words on blue show it. At quality 100 they scored only 29.3 dB. Sharp YUV, a slower colour conversion, raised that to 30.5 dB. Lossless WebP was exact, and smaller than both at 3.4 KB.

Near-lossless WebP

Near-lossless WebP nudges pixel values so they compress better, then saves them losslessly. Its level runs from 0 to 100, where 100 changes nothing and 60 is typical. On text and the logo, level 60 was smaller than lossless and scored over 60 dB. On the photos, lossy 100 was smaller, which Google’s cwebp page warns can happen.

What quality do apps and browsers use for WebP?

Most tools start at 75 or 80, so two “default” WebPs of our photo differ by 20% in size. We read each maker’s page on 1 November 2026. A page can also ask the browser for a WebP with canvas.toBlob, and the standard leaves that default to each browser. We measured those ourselves.

The defaults come from Google’s cwebp page, the libvips, ImageMagick, sharp and Pillow manuals, Squoosh’s code and WordPress’s image editor code.

WordPress is the odd one. It saves WebP at 86, above its own JPEG default of 82. A 2021 ticket proposed 82 for both. Testers found one portrait needed WebP 90 to match, and the ticket closed as “maybelater” in 2024.

Safari’s canvas cannot write WebP at all. It shows WebP fine, but a canvas asked for image/webp hands back a PNG, as the standard allows. A page that makes WebP in the browser should check blob.type before it uploads.

Blinkimg’s Auto is 75 for a photo and 82 for a graphic. On a graphic that comes in as PNG, it also tries lossless WebP and keeps the smaller file. Our logo and flat art came out lossless, at 8.5 KB and 0.2 KB. On the text card, quality 82 made 26.6 KB, just under its 27.0 KB lossless file, so Auto kept the lossy one.

Other WebP settings that change the file size

Quality is not the only dial. Effort, called -m in cwebp, sets how hard the encoder searches. It changes the size at the same quality, and the time it takes. On our photo at quality 75, effort 0 made a file 63% bigger than the default of 4. Effort 6 saved 4% more for 72% more time.

• Sharp YUV (-sharp_yuv, sharp’s smartSubsample): cleaner colour edges on text and logos, at a slower encode. Blinkimg turns it on for graphics only.
• Alpha quality (-alpha_q): the quality of the transparency, separate from the colour. It defaults to 100, which keeps the edges of a cut-out exact.
• Presets (-preset photo, text, icon): cwebp’s bundles of settings for one kind of image.

Should I use WebP?

Yes, for images on a web page. At the same SSIM, our WebPs were 10% to 23% smaller than JPEG on photos, and under half the size on the screenshot, text and logo. caniuse counts 97.08% of users with full WebP support.

Keep another format for files you will edit, print or email. A WebP saved again loses a little more each time, and some apps and email clients still refuse it. Our WebP vs PNG post measures those cases. AVIF is smaller again; AVIF vs WebP compares the two on the same photo.

How to set WebP quality

Every encoder takes the number the same way: one option, on the save. The lines below set quality 75 for a photo, and lossless or near-lossless for graphics. Leave quality out and each tool uses its default from the table above.

Already have JPEGs saved at 80? Convert them at 85, not 75: on our photos, WebP 85 scored the same SSIM as JPEG 77 to 81. Our JPG to WebP converter prints each file’s size before you download it.

How we tested

• The images: our iguana photo (1916 × 1276), our camera photo of a boat at sunset (1920 × 1076), a 2880 × 1800 screenshot of our pricing page, and three we drew: a text card, a soft-edged logo and flat colour blocks.
• The files: Blinkimg’s engine, version 12, at each quality (sharp 0.35.5, libvips 8.18.7, libwebp 1.6.0). Lossless and near-lossless WebP and every JPEG came from sharp directly. Measured 2026-11-01 on an Apple M1 Pro, 8 cores.
• The scores: PSNR over RGB, and SSIM over brightness with an 11-pixel window. The matching JPEG quality is read off a JPEG saved at every quality from 20 to 100. How we measure has the rest.
• The browsers: Playwright’s Chromium 149.0.7827.55, Firefox 151.0 and WebKit 26.5, a 960 × 640 photo saved at 101 qualities and compared byte for byte with the default.