Choosing Between Lossy and Lossless Compression

The single most consequential decision in image encoding is also the simplest: lossy or lossless. WebP supports both modes, and choosing wrong inflates your file sizes by up to 10× or ships visible artefacts on content that cannot tolerate them. This guide gives you a decision framework that works for any image.

For the encoder parameters that go with each mode, see WebP Compression Settings. For where this choice fits in the broader performance picture, see WebP Optimisation.

What each mode actually does

Lossy

Lossy compression discards image data permanently. The encoder analyses the image, decides which information the human eye is least likely to miss, and throws it away. The decoded image is mathematically different from the source but visually similar.

WebP's lossy mode is based on VP8, the same codec family that powers WebM video. It works by:

Splitting the image into 16×16 pixel "macroblocks".
Predicting each block's content from its neighbours.
Encoding only the difference between the prediction and the actual content.
Quantising that difference based on the quality factor.

The quality factor (-q, 0–100) controls how aggressively the quantisation discards information. Lower numbers = more aggressive = smaller files = more artefacts.

Lossless

Lossless compression reorganises the image data without discarding any. The decoded image is bit-identical to the source. WebP's lossless mode uses a combination of:

Predictor transforms — describe each pixel as a function of its neighbours.
Colour transforms — exploit correlations between R, G, and B channels.
Subtract-green transform — encode R and B relative to G (since photographs tend to have green-dominant luminance).
Colour indexing — for images with ≤ 256 colours, store an index instead of full RGB.
LZ77 backward references — find repeated pixel sequences.

The result is roughly 25% smaller than PNG at the same fidelity.

Near-lossless

A hybrid: lossy encoding tuned so aggressively toward fidelity that the output is visually identical to the source at typical viewing conditions. Compresses 25–40% better than full lossless. Covered in detail in WebP Compression Settings.

The decision framework

Three questions, in order. The first that answers "yes" decides the mode.

Question 1: Does the image have flat colour fills or hard edges?

Logos, icons, line art, screenshots of UI, charts, and diagrams contain large areas of identical colour and sharp transitions between regions. These compress dramatically better as lossless because:

The flat fills become single backward-references in the LZ77 stream.
The hard edges are preserved exactly, with no ringing or blocking artefacts.
The limited palette often qualifies for colour indexing.

Encoding these as lossy at any quality produces visible artefacts: ringing around text, banding on flat fills, fuzz at hard edges. Even at q=95, lossy WebP is worse than lossless for this content.

→ If yes: use lossless.

Question 2: Is the source already a lossy file (JPEG)?

If the source is a JPEG, you have already taken one lossy pass. Encoding the JPEG as lossy WebP at any quality below ~85 stacks a second lossy pass on top, compounding the artefacts.

Two valid approaches:

Encode as lossy WebP at q=80–82. The file will be smaller than the JPEG and visually indistinguishable at typical viewing conditions. The double-lossy concern is overblown for q ≥ 80.
Encode as near-lossless. Larger output but no risk of compounding artefacts.

Avoid encoding a JPEG as lossless WebP — you are losslessly preserving artefacts that are already in the source, paying full lossless file size for no fidelity gain.

→ If yes: use lossy at q=80+ (or near-lossless if you are paranoid about cumulative loss).

Question 3: Is the image photographic content?

Photographs, paintings, renderings, and any other content with smooth gradients, organic textures, and continuous tone fall into this bucket. They compress poorly as lossless because:

They contain no flat fills to exploit.
Every pixel is slightly different from its neighbours.
The colour palette is effectively unlimited.

Lossless WebP of a photograph is typically 2–4× the size of lossy WebP at q=80, with no visible benefit.

→ If yes: use lossy.

If none of these questions answered yes, you have an unusual case — typically a synthetic image with photographic-like content (3D rendering with smooth gradients but sharp UI overlays). In that case, near-lossless is usually the best compromise.

Decision matrix by content type

Content	Mode	Why
Brand logo	Lossless	Hard edges, flat fills, must stay crisp
App or web UI icon	Lossless	Small, detailed, hard edges
Screenshot of an interface	Lossless or near-lossless	Text and edges must remain readable
Screenshot of text	Lossless	Anti-aliased text artefacts under lossy
Hand-drawn illustration	Lossless	Linework needs preservation
Chart, graph, or diagram	Lossless or near-lossless	Edges and labels critical
Product photo on white	Lossy	Photographic content; alpha optional
Hero photo	Lossy at q=82	Visible at large size; quality matters
Article body photo	Lossy at q=75	Below-the-fold, smaller viewport
Photo thumbnail	Lossy at q=65	Small render size hides aggressive compression
Photo of a document	Near-lossless	Text readability + photographic source
Generative AI image	Lossy	Photographic-like content
3D render (smooth)	Lossy at q=85	Photographic-like; high quality recommended
3D render (with UI overlay)	Near-lossless	Hybrid content
Animated GIF replacement	Lossy animated	Always smaller than lossless animation

File size comparison

Rough rules of thumb. Numbers vary by content, but the relationships are stable:

Photo, lossless WebP ≈ 2–4× lossy WebP at q=80
Photo, lossy WebP at q=80 ≈ 25–35% smaller than equivalent JPEG
Photo, lossy WebP at q=80 ≈ 50–70% smaller than equivalent PNG
Logo, lossless WebP ≈ 25% smaller than PNG
Logo, lossy WebP at q=90 ≈ visible artefacts; larger than lossless
Animated WebP ≈ 30–60% smaller than equivalent animated GIF

If the lossy version of an image is bigger than the lossless version, you chose the wrong mode.

Visual quality trade-offs

What lossy compression actually does to an image, by quality factor:

q=90–100: differences invisible to nearly all viewers. Diminishing returns above q=90.
q=75–89: differences detectable only by side-by-side pixel inspection on a colour-calibrated display.
q=60–74: differences visible to attentive viewers on close inspection. Acceptable for thumbnails and below-the-fold imagery.
q=40–59: artefacts visible during normal viewing. Use only for decorative or deliberately compressed effects.
q=0–39: significant artefacts. Avoid in production.

What lossy compression does badly:

Anti-aliased text: ringing artefacts around character edges.
Hard edges in line art: fuzz and chromatic distortion.
Flat colour fills: banding visible at low quality.
Single-pixel detail: smoothed away by quantisation.

Lossless is bit-perfect — none of these artefacts apply by definition.

Common mistakes

Encoding everything as lossless "to be safe"

Lossless WebP is excellent for the content it suits and wasteful for the content it does not. Encoding a 4000×3000 hero photograph as lossless WebP routinely produces a 5–8 MB file. The same image at lossy q=80 is 300–500 KB and visually identical. The instinct to default to lossless is wrong for any photographic content.

Encoding everything as lossy at q=95

The opposite mistake. Encoding logos and icons as lossy q=95 produces files that are simultaneously larger than the lossless version and contain artefacts. Lossy is not "lossless for content that should be lossless" — it is a different mode with different failure modes.

Encoding screenshots as lossy

Screenshots are the trap. They look photographic — they are rendered to a pixel grid — but they contain large areas of flat colour, hard UI edges, and anti-aliased text. Lossy compression of a screenshot at any reasonable quality produces visible artefacts around text. Use lossless or near-lossless.

Treating quality factor as linear

A q=80 image is not "80% as good" as a q=100 image. Quality scales nonlinearly: q=100 to q=90 loses very little; q=90 to q=80 loses a little more; q=80 to q=70 loses noticeably more; q=50 to q=40 loses dramatically more. Anchor your settings to the upper end of the curve.

Animated content

Animated GIFs are a special case. Replacing them with animated WebP is almost always a win:

Animated WebP supports up to 16-bit colour vs GIF's 8-bit palette.
Animated WebP supports alpha channel; GIF does not.
Animated WebP files are typically 30–60% smaller.

For animated content, lossy is almost always the right choice. Even at high quality, animated lossy WebP beats animated GIF on both fidelity and file size. See GIF to WebP.

Where to go from here

WebP Compression Settings — encoder parameter reference for both modes
WebP Optimisation — how mode choice fits into broader performance work
WebP Browser Support — what you can ship today
WebP format overview — technical detail on both compression types
Convert your content: PNG to WebP, JPG to WebP, GIF to WebP
Compare: WebP vs PNG

Mode choice is the single decision that determines whether the rest of your WebP optimisation work pays off. Answer the three questions in order, and the right mode falls out.