Lossy vs lossless image compression

Published: 2026-09-05

How JPEG, PNG, and WebP trade quality for file size, when lossless still wins, and how to resize and re-encode photos locally without uploading them.

Image compression shrinks how many bytes you store or send while keeping a picture that still looks right for the job. The big fork in the road is lossy vs lossless: whether the encoder is allowed to throw away detail that humans are unlikely to notice, or whether every pixel of the decoded bitmap must match the source bitmap exactly.

That choice drives format selection (JPEG vs PNG vs WebP), quality sliders, and whether a “smaller file” is safe for logos, screenshots, and archival masters.

Lossy vs lossless in one minute

	Lossy	Lossless
Goal	Smaller files by discarding hard-to-see detail	Smaller files by packing the same pixels more efficiently
Round-trip	Decode ≠ original pixels (artifacts possible)	Decode matches the bitmap you encoded
Typical formats	JPEG, lossy WebP, lossy AVIF	PNG, lossless WebP, GIF (indexed)
Best for	Photos, hero images, user-generated uploads	UI icons, screenshots with text, graphics with flat color

Lossy codecs exploit how vision works: mild blur in busy foliage is cheaper to notice than ringing around sharp text edges. Lossless codecs still compress—run-length packing, filters, dictionaries—but they never “invent” a softer edge to save bytes.

Important nuance: “lossless” means pixel-exact for that bitmap, not “identical to the camera RAW” or “never changed by editing.” Resizing, color-profile conversion, or flattening transparency all change pixels before you encode—even if the final encode is lossless.

JPEG, PNG, and WebP (practical map)

Format	Compression style	Transparency	Typical sweet spot
JPEG	Lossy (quality 1–100-ish)	No alpha	Photos, large marketing images
PNG	Lossless (of the bitmap)	Yes (alpha)	Logos, UI, screenshots, diagrams
WebP	Lossy or lossless (encoder mode)	Yes	Modern web defaults; often smaller than JPEG/PNG at similar look

MIME labels for these files are covered in MIME types and file extensions (image/jpeg, image/png, image/webp). The extension is a hint; the bytes and Content-Type are what browsers and CDNs actually trust.

WebP as a default for the web is popular because a single family covers both modes and usually beats JPEG at the same visual quality—and often beats PNG for simple graphics when you allow a careful lossy or lossless encode. Support is mainstream in current browsers; keep a JPEG/PNG fallback only if you still target very old clients.

SVG is a different story: it is vectors and markup, not a photo bitmap. Shrinking SVG is about cleaning path data and metadata (SVG to React: cleanup and JSX patterns, SVG Minifier), not a JPEG-style quality knob.

Quality sliders and what they actually do

In lossy encoders, quality (or CRF / similar knobs in other tools) budgets how aggressively the codec may discard detail:

High quality (e.g. 85–95) — subtle savings vs the source; fine for hero photos when you still want crispness.
Medium (e.g. 70–80) — common web compromise; often “good enough” on retina displays where CSS display size is smaller than pixel dimensions.
Low (below ~60) — banding, blockiness, muddy text; useful for tiny thumbnails, risky for product close-ups.

Lossless formats generally ignore a quality slider for true lossless mode, or the UI remaps “quality” to something else (filter effort, palette size). If you export PNG from a browser canvas, you are asking for a lossless encode of whatever pixels are on the canvas—not a second JPEG pass.

Repeated lossy re-encoding (open JPEG → edit → save JPEG → edit again) stacks artifacts. Prefer a lossless or high-bit-depth master for editing, then export lossy once for delivery.

Resize is half the win

Many “huge” images are simply too many pixels for how they are shown. A 4000×3000 phone photo displayed at 800 CSS pixels wastes bandwidth even at high JPEG quality. Constraining max width / max height (and keeping aspect ratio) often saves more than nudging quality alone.

Rules of thumb:

Match export dimensions to the largest layout size you need (plus a modest retina factor if you serve 2x assets).
Do not upscale to “add quality”—you invent pixels and grow the file.
For responsive sites, prefer multiple widths or a modern srcset strategy over one gigantic master in every <img>.

When to prefer lossless (or near-lossless)

Choose PNG / lossless WebP (or keep a lossless master) when:

Text and UI chrome must stay sharp (docs screenshots, marketing UI captures).
Flat brand colors and hard edges matter more than photographic grain.
You need alpha and will composite over unknown backgrounds.
The asset is a source of truth you will re-export from later.

Choose lossy JPEG / lossy WebP when:

The subject is a photograph or busy illustration.
You care about LCP / bytes on the wire more than bit-exact pixels.
Slight softness is acceptable at the displayed size.

Compress locally (privacy and workflow)

Online compressors often upload every frame to a server. Product shots, ID scans, and unpublished creatives should not take that trip if you can avoid it. Browser tools that decode and re-encode with the Canvas API keep pixels on the device—same privacy model as other local developer utilities (Why “local only” matters for developer tools).

What canvas-based optimizers are good at:

Re-encoding to JPEG / PNG / WebP with a quality setting where the format supports it.
Resizing to max width/height before encode.
Side-by-side before/after checks so you stop when artifacts appear.

What they are not: a full replacement for specialized PNG crushers, Zopfli, or studio pipelines that tune every filter. For day-to-day web assets and batch phone dumps, local canvas encode + resize is usually enough.

Try it on LocalTools

Open Image Optimizer:

Drop up to 10 images (PNG, JPG, WebP, GIF, BMP, and similar).
Set quality, optional max width/height, and output format (Original, WebP recommended, JPEG, or PNG).
Compare with the before/after slider; download one file or a ZIP of all results.

Processing stays in your tab—nothing is uploaded for optimization.