You export an image as WebP and hit a wall almost immediately: a quality slider from 0 to 100, and no clear sense of what number actually belongs there. Leave it at 100 "to be safe" and you barely save any bytes over the original. Drag it down to 40 chasing a smaller file and suddenly your product photo has soft, blotchy patches around the edges. Most people either over-compress by accident or never compress at all, simply because the slider gives no feedback about what it's actually doing to the image.
WebP's quality setting isn't a mystery once you understand what it controls — and once you know that "quality" means something slightly different depending on whether you're using WebP's lossy or lossless mode, whether you're compressing in a browser tool or through Android's SDK, and how WebP now sits next to newer formats like AVIF. Get those distinctions right and picking a number stops being guesswork. This guide covers all of it — the desktop and web workflow, the Android-specific behavior developers keep tripping over, and where WebP wins or loses against JPEG and AVIF — so you only need one page open, not five.
For lossy WebP, a quality setting of 75–85 is the sweet spot for most photographs — small files with no visible loss. Push to 90+ for detail-heavy images like product close-ups or screenshots with text. For logos, icons, and anything needing pixel-perfect transparency, skip the quality slider entirely and use lossless WebP instead. On Android, quality behaves differently depending on your target SDK version — see the dedicated section below before you set a number in code.
What is WebP compression quality, really?
WebP is actually two formats bundled under one file extension, and "quality" means something different in each one.
- Lossy WebP — works similarly to JPEG. A quality value from 0-100 controls how much fine detail the encoder is allowed to discard, particularly in busy, high-frequency areas of the image. Lower numbers mean smaller files and more discarded detail; higher numbers mean larger files that stay closer to the source.
- Lossless WebP — works similarly to PNG. Every pixel is preserved exactly, so there's no quality slider to tune in the traditional sense — instead, encoders expose a "compression effort" or "method" setting that trades encoding time for a smaller file, without ever discarding image data.
- Near-lossless WebP — a middle ground, using a quality-like value (typically 0-100) to control a light preprocessing pass before lossless compression, shaving off extra bytes at a cost that's usually imperceptible.
There's one more wrinkle worth knowing: in lossy WebP, the alpha (transparency) channel is compressed separately from the RGB color data, with its own quality behavior. That means a lossy WebP with transparency can look fine in its colors but show soft or slightly off edges around the transparent parts if the alpha compression is too aggressive. Some encoders — and server-side optimization engines that auto-compress images before they reach the browser — expose this as a separate "alpha quality" value so you can keep transparency crisp even while compressing color data harder.
What does WebP stand for, and where did it come from?
WebP stands for "Web Picture." Google released it in 2010, building it on the same underlying prediction techniques used in its VP8 video codec, with one goal: make images smaller for faster page loads without a visible quality trade-off. It was one of the first mainstream formats to bundle lossy compression, lossless compression, transparency, and animation into a single file type — previously you needed JPEG for lossy photos, PNG for lossless graphics and transparency, and GIF for animation. WebP folds all three use cases into one format, which is a large part of why Google's own PageSpeed Insights and Lighthouse tools flag "serve images in next-gen formats" as a top recommendation on almost every site they audit.
Figures reflect commonly cited Google encoder benchmarks comparing WebP against equivalent-quality JPEG and PNG source images; actual savings vary by image content.
Why the right quality setting matters
The quality slider isn't a minor detail — get it wrong in either direction and it costs you something real:
- Wasted bandwidth. Exporting every image at quality 95-100 "to be safe" routinely doubles or triples file size over quality 80, for a difference most viewers will never notice.
- Visible artifacts. Push quality too low on a photo and you'll see blocky patches, color banding, or smearing in areas with fine texture — skies, skin tones, and gradients show it first.
- Broken transparency edges. Low lossy-alpha quality on a logo or icon can introduce faint fringing or softness around transparent boundaries that's easy to miss until it's live.
- Compounding loss. Re-saving a lossy WebP as lossy WebP again during editing stacks another round of compression on top of the last, degrading the image a little more each time.
- Slower Core Web Vitals. Oversized images are one of the most common causes of a poor Largest Contentful Paint (LCP) score, which directly affects both user experience and search ranking signals.
Step-by-step: how to choose the right WebP quality
- Decide lossy or lossless first. If the image needs pixel-perfect edges, sharp text, or exact transparency (logos, icons, UI screenshots), start from lossless WebP. If it's a photograph or photo-like image, start from lossy.
- For photographs, start at quality 80. This is the practical default most encoders and optimization tools converge on — visually very close to quality 100, at a fraction of the file size.
- Check for artifacts at real display size. Zoom back out to the size the image will actually appear at on the page. Blockiness or smearing that's obvious at 400% zoom often disappears completely at normal viewing size.
- Raise quality for detail-heavy images. Product close-ups, screenshots with small text, or images with fine patterns hold up worse at low quality. Push these to 90-95 rather than the general 80 default.
- If the image has transparency, check the alpha edges separately. Some encoders let you set alpha quality independently from RGB quality — keep alpha quality high even if you lower the color quality, since edge artifacts are more visible than color noise.
- For flat graphics, skip the slider and use lossless. Logos, icons, and line art have little detail for lossy compression to discard, so lossless WebP is usually both smaller and cleaner than a lossy version at any quality setting.
- Consider compression context, not just the number. Mobile connections and smaller viewport sizes can usually tolerate a slightly more aggressive quality setting than a large desktop hero image, since fine detail is less visible at smaller render sizes.
- Compare file size and visuals side by side before shipping. Export the same image at 2-3 quality values and check both the byte count and how it actually looks at real size — the numbers usually make the right setting obvious.
WebP compression quality settings on Android
If you're setting WebP quality in an Android app rather than exporting from a design tool or
website compressor, the behavior is genuinely different — and it has changed across SDK
versions, which is why this trips developers up. Quality is set through
Bitmap.CompressFormat and a quality integer from 0-100 passed to
Bitmap.compress(), but what that number does depends on your target API level.
- API 14-17: Only lossless WebP is supported at all.
- API 18-28: Both lossy and lossless are supported, but they share a single
WEBPformat constant. A quality value of 100 automatically produces a lossless WebP; anything from 0-99 produces a lossy WebP at that compression level. - API 30+: Android deprecated the single combined format and replaced it with two explicit constants —
CompressFormat.WEBP_LOSSYandCompressFormat.WEBP_LOSSLESS. You now choose the mode explicitly instead of relying on quality 100 to switch it for you, and the quality value only controls compression strength within whichever mode you picked.
This matters in practice because code written for older SDKs that assumes "quality 100 = lossless"
will silently behave differently — or trigger a deprecation warning — once the app targets API 30
or higher. If you maintain an app across a wide range of supported devices, explicitly picking
WEBP_LOSSY or WEBP_LOSSLESS rather than relying on the quality value alone
is the safer long-term approach.
Android Studio's built-in image converter (right-click an image asset → Convert to WebP) follows the same logic: it shows a live before/after preview as you drag the quality slider, and if lossless encoding is available for your minimum SDK, setting quality to 100 switches the converter to lossless mode automatically. For app icons, illustrations, and UI assets with flat color, lossless is usually the better call; for photographic content bundled into the app, treat it the same as web images — start around 75-85 and adjust from there based on visible artifacts.
WEBP_LOSSY /
WEBP_LOSSLESS constants rather than the deprecated combined WEBP format —
it avoids ambiguity and matches how newer devices actually interpret the quality value.
WebP vs JPEG vs AVIF: which format actually wins?
WebP isn't the only modern option anymore. AVIF, based on the AV1 video codec, has emerged as an even more efficient format for many images, and Google's own PageSpeed recommendations now mention both. Here's how the three actually compare in practice, not just on paper.
| Format | Typical size vs JPEG | Transparency | Browser support | Encoding speed |
|---|---|---|---|---|
| JPEG | Baseline | No | Universal | Fastest |
| WebP | ~25-34% smaller | Yes | All modern browsers | Fast |
| AVIF | ~40-50% smaller | Yes | Broad, but younger support | Slower to encode |
Independent testing across large photo sets has found AVIF trimming roughly another 15-20% off an already-compressed WebP file at comparable visual quality, and AVIF also handles HDR color and higher bit depth (up to 12-bit, versus JPEG's 8-bit ceiling) — a real advantage for photography-heavy sites. So why isn't everyone using AVIF exclusively? Two practical reasons:
- Encoding cost. AVIF compression is meaningfully slower than WebP at the same quality target, which matters if you're compressing large batches or generating images on the fly.
- No progressive rendering. Neither WebP nor AVIF currently support progressive rendering the way JPEG does, so on very slow connections a JPEG can start appearing sooner even if it finishes loading later.
The practical answer most sites land on: serve AVIF where you can, fall back to WebP, and fall
back again to JPEG or PNG for anything that supports neither — which is exactly what the
<picture> element below is built for. For images your visitors are likely to
zoom into, like e-commerce product photography, keeping quality high (or lossless) matters more
than squeezing every extra byte out with a newer format; for decorative or supporting images,
it's the opposite — push compression harder, since the visual cost is barely noticeable.
Serving WebP with automatic fallback (the <picture> tag)
Compressing an image correctly only helps if the browser actually receives the best format it
supports. The standard way to do that without extra JavaScript is the HTML
<picture> element, which lets the browser pick the first format it understands
from a list, in order:
The browser checks each <source> in order and uses the first format it
supports — AVIF first if available, then WebP, then falling back to the plain
<img> tag's JPEG or PNG for anything older. This is content negotiation done
entirely by the browser with no server logic required, and it means you never have to choose
one format for every visitor — everyone gets the smallest file their browser can actually
decode. Keep the alt text on the fallback <img> tag, since that's
what accessibility tools and search engines read regardless of which source loads.
Common mistakes that cost you quality or speed
1. Leaving quality at 100 for every image
Quality 100 feels like the "correct" choice, but for photographic content it produces files that are often 2-3x larger than quality 85 with no visible difference to most viewers. Treat 100 as reserved for source masters, not for what actually ships to the browser.
2. Chasing the smallest possible file with quality below 50
Dropping quality aggressively to hit a target file size introduces visible blockiness and color banding, especially in skies, gradients, and skin tones. If a target file size is genuinely necessary, resize the image dimensions down first rather than crushing the quality value.
3. Ignoring alpha quality on transparent images
A lossy WebP logo can look fine in a quick preview but show soft, slightly inaccurate edges once placed over a busy background — because alpha channel compression was left at the same low setting as the color data. For anything with transparency where edges matter, lossless WebP avoids this entirely.
4. Re-compressing an already-lossy WebP
Opening a lossy WebP, editing it, and re-exporting as lossy WebP again stacks a second round of compression on top of the first, compounding artifacts. Keep an uncompressed or lossless master and only export to lossy WebP as the final step.
5. Relying on quality 100 to trigger lossless mode on newer Android targets
This worked reliably on API 29 and below, but on API 30+ the combined WEBP format
constant is deprecated in favor of explicit WEBP_LOSSY and WEBP_LOSSLESS
constants. Code that hasn't been updated may still compile with a deprecation warning, but
explicitly choosing the mode is the more future-proof pattern.
Real-world examples
These are representative results from exporting the same source image at different WebP settings:
The pattern holds across content types: a moderate lossy quality (80-85) handles photographic content extremely well, detail-heavy images need a push toward 90+, and anything relying on flat color or precise transparency is better served by lossless WebP than by any lossy quality value. Where AVIF support is safe for your audience, it typically shaves off another meaningful chunk on top of WebP's savings — at the cost of slower encoding.
WebP quality level comparison table
A quick reference for what to expect at each common quality setting.
| Setting | Typical use | Visual result | File size |
|---|---|---|---|
| Lossless | Logos, icons, screenshots, transparency | Pixel-perfect | Larger for photos, small for flat graphics |
| Quality 90-100 | Product close-ups, text-heavy images, masters | Near-indistinguishable | Moderate |
| Quality 75-85 | General photographs, blog and hero images | No visible loss at normal zoom | Small — the everyday sweet spot |
| Quality 50-70 | Thumbnails, low-priority background images | Minor softness, usually acceptable | Very small |
| Quality below 50 | Rarely appropriate | Visible blocking and banding | Smallest, but often not worth the artifacts |
Converting WebP to JPG or PNG (and why your OS keeps saving WebP)
Two related questions come up constantly: why does a screenshot or downloaded image suddenly
save as .webp, and how do you get it back to a more universally-editable format?
Why your computer or browser is saving images as WebP
This almost always comes from the source, not your device. Many modern websites — and Chrome's own screenshot and "save image" behavior in some contexts — now serve or generate WebP by default, since it's smaller and every major browser supports it. Your computer isn't converting anything; it's simply saving the file exactly as it was served or captured. If you need a different format for compatibility with older software, converting after the fact is the fix, not disabling WebP somewhere in your settings.
Converting to JPG without unnecessary quality loss
Whether a conversion is truly "lossless" depends on where the file started:
- Starting from a lossless WebP: converting to a high-quality JPEG (95-100) preserves it almost losslessly — JPEG itself always applies some compression, but at quality 95+ the difference is generally imperceptible.
- Starting from a lossy WebP: the quality loss already happened during the original WebP export. Converting to JPG cannot undo that — it just carries the existing loss into a new file, which will usually be larger for the same visual result.
- Starting from a lossy WebP and converting to PNG: PNG is lossless, so no further loss is added — but the file will be considerably larger, since PNG has to losslessly store detail that WebP already discarded, rather than restoring anything.
Practically, if you need JPG or PNG for compatibility with an older tool, format, or platform, do the conversion — just don't expect it to reverse compression that already happened. If you still have access to the original source image, re-exporting from that source directly to your target format will almost always produce a cleaner result than converting an already-compressed WebP.
Are WebP files safe?
Yes. WebP is an open, publicly documented format maintained by Google, and there's nothing inherently risky about the file type itself — it's just a container for compressed pixel data, the same as JPEG or PNG. The general security guidance that applies to any image format applies here too: keep your browser, operating system, and image-viewing software updated, since image decoders (for any format) can occasionally have vulnerabilities that get patched over time. There's no evidence WebP as a format carries meaningfully more risk than JPEG or PNG — the concern some people raise usually comes from unfamiliarity with a newer file extension rather than an actual security difference.
Compress your WebP right now — free
The Rebrixe WebP Compressor runs entirely in your browser. Adjust quality with a live before/after preview, compare file sizes instantly, and switch between lossy and lossless — your images are never uploaded to a server. No account, no file size limit, no watermarks.