JPEG, WebP, and quality sliders: artifacts, banding, and when recompression hurts

Lossy image compression is a trade: fewer bytes for imperceptible (hopefully) changes. In practice, teams fight blockiness in flat areas, ringing around sharp edges, color banding in gradients, and the special hell of text inside JPEGs. This article explains what you are seeing when you drag a quality slider, why screenshots and photos behave differently, and how Image compress on toolit supports informed choices - still in your browser, without uploading originals to us.

This is not a math textbook; it is the conceptual layer that stops you from cargo-culting “always 80% quality” across every asset type.

What lossy codecs actually do (intuition-level)

Both JPEG and WebP (lossy mode) throw away information humans are unlikely to notice at normal viewing conditions. They are not “shrinking the PNG” - they re-encode pixel data with different assumptions.

JPEG divides the image into blocks (commonly 8×8) and quantizes frequency components. That is why heavy JPEG compression shows block boundaries and mosquito noise around edges.

WebP lossy uses different techniques (including block prediction and adaptive filtering in various modes) and often beats JPEG on bytes for similar visual quality on photographic content - but “often” is not “always.”

Important: re-saving a lossy file again and again accumulates damage. If your pipeline exports JPEG → someone opens and re-saves JPEG at lower quality → you get generation loss. Prefer working from a master (PNG, TIFF, or high-quality source) when possible.

Artifact tour: what to look for when comparing

Blockiness and macroblocking

Flat regions (sky, walls) show chunky squares when quality is too low. Photos tolerate some of this better than UI shots because noise hides blocks.

Ringing (halos)

Sharp transitions (text on white, black lines) get overshoot artifacts - faint halos near edges. Bad for screenshots and diagrams.

Color banding in gradients

Smooth gradients turn into stripes when the codec does not have enough precision for subtle color steps. This shows up in slides, hero backgrounds, and dark mode UIs with subtle vignettes.

Text inside lossy images

If your “image” is mostly text, JPEG is often the wrong tool - consider PNG, SVG, or real HTML text. If you must JPEG a screenshot, higher quality and careful dimensions help - but you are fighting the format.

Photos vs screenshots vs illustrations

Quality sliders: percentages are not universal

“Quality 80” in one exporter is not identical to “80” in another tool. Relative comparisons on the same tool matter more than the number itself.

Workflow that works:

1. Export at a mid quality.
2. View at real size on a typical monitor and on a phone.
3. If you only see issues at 200% zoom, you may be over-serving bytes.
4. If text looks fuzzy at 100%, bump quality or change format.

toolit lets you compare before download - use your eyes, not only the byte count.

WebP vs JPEG: stop asking which is “better”

Ask: which is smaller at acceptable quality for this asset?

• Photo-heavy marketing image: try WebP first; compare.
• Legacy CMS only accepts JPEG: optimize JPEG intelligently.
• Need transparency without insane size: evaluate WebP with alpha or PNG depending on complexity.

Our Image compress page exists so you can run those comparisons locally without emailing files to a stranger’s queue.

Dimensions still beat codec religion

A stunning WebP at 4000px wide shown in a 360px column still wastes bandwidth decoding pixels users never see. Image crop and Rotate image belong in the pipeline before you obsess over codec settings.

Order of operations (repeat until it is muscle memory):

1. Rotate / straighten so composition is correct.
2. Crop to the intended aspect and subject.
3. Resize to reasonable pixel dimensions for delivery (toolit or your editor).
4. Compress with the right format and quality.

Skipping straight to step 4 optimizes the wrong problem.

When “optimize everything” is wrong

Archival masters should not be lossy-compressed into oblivion. Keep a source of truth for brand assets. Derivatives are what go on the web.

Print and web are different targets - do not let the web team recompress print PDFs without coordination.

FAQ

Should I always prefer WebP? No - test. Especially for graphics with sharp lines, verify edges.

Does PNG recompress to WebP always reduce size? Usually yes for photo-like PNGs; not always for tiny palettes or already optimal PNGs.

Why does my double-JPEG look awful? Generational loss. Go back to a lossless or high-quality master.

Side-by-side comparison discipline

When evaluating compression:

• Match zoom level - comparing a thumbnail view hides artifacts you will see fullscreen.
• Check different backgrounds - dark UI themes expose banding that light themes hide.
• Test on a cheap monitor and a good monitor - teams that only review on calibrated displays ship surprises for everyone else.

toolit’s compare flow is built for quick iteration: if two exports look identical at real size but one is 40% smaller, you have a winner.

Accessibility tie-in: smaller files help real users

Heavy images slow LCP and cost data - especially on capped mobile plans. Faster loads are not only a Core Web Vitals game; they reduce cognitive load (“is this page broken?”) and help users who rely on zoom or screen magnification because the page becomes interactive sooner.

Closing

Quality sliders are not superstition and WebP is not a spell - they are tools. Learn the artifacts, respect dimensions, avoid recompression chains, and use Image compress to compare outcomes on your assets, your screen, your risk tolerance.

The best optimization is the one you ship because you understood the trade - not the one you abandoned because the pipeline was too opaque.