Image Compression: How Quality Sliders Actually Work

Every image editing application, every export dialog, and every web-based compression tool presents you with a quality slider — usually ranging from 0 to 100. You learn through experience that somewhere around 75 to 85 produces files that look identical to the original at a fraction of the size, and that anything below 40 starts looking noticeably degraded. But what is actually happening when you move that slider? What does "quality 80" mean at the byte level, and why does the visual difference between 95 and 100 seem negligible while the file size difference is enormous?

This article explains the mechanics of image compression — specifically lossy compression as used in JPEG and WebP — from the signal processing fundamentals through to the practical decisions you make when choosing a quality level. Understanding what the slider controls helps you make better compression decisions and explains why different images respond to compression differently.

Lossy vs. Lossless: The Fundamental Split

Image compression falls into two categories. Lossless compression reduces file size without discarding any image data — the decompressed result is bit-for-bit identical to the original. PNG uses lossless compression based on the DEFLATE algorithm. Lossless compression typically achieves 2:1 to 3:1 reduction ratios for photographic content, which is often not enough for web delivery where file size budgets are tight.

Lossy compression permanently removes some image data to achieve much higher compression ratios — 10:1, 20:1, or even 50:1 depending on the quality setting. The removed data is chosen strategically based on models of human visual perception, targeting information that the eye is least likely to miss. JPEG, WebP (in lossy mode), and AVIF all use lossy compression. The quality slider controls how aggressively data is removed.

The distinction matters because lossy compression is a one-way operation. Once data is discarded, it cannot be recovered. Re-saving a JPEG at quality 100 does not restore detail lost in a previous save at quality 60 — it just re-encodes the already-degraded image with minimal additional loss. This is why photographers and designers work in lossless formats (RAW, PSD, PNG) during editing and only export to lossy formats as a final step.

The JPEG Compression Pipeline

JPEG compression is a multi-stage pipeline, and the quality slider specifically controls one stage — quantization. Understanding the full pipeline reveals why that single parameter has such a dramatic effect on both file size and visual quality.

Stage 1: Color space conversion. The image is converted from RGB to YCbCr, a color space that separates luminance (brightness, the Y channel) from chrominance (color information, the Cb and Cr channels). This separation is not just a mathematical convenience — it is the foundation of JPEG's compression strategy, because human vision is far more sensitive to changes in brightness than to changes in color.

Stage 2: Chroma subsampling. Because the eye has lower spatial resolution for color than for brightness, the chrominance channels can be stored at lower resolution with minimal perceptible impact. The most common subsampling mode, called 4:2:0, stores chrominance at half the horizontal and half the vertical resolution of the luminance channel — effectively reducing the color data by 75 percent. This alone cuts the data that needs to be compressed by roughly a third before any frequency-domain processing begins.

Stage 3: Block splitting and DCT. The image is divided into 8 by 8 pixel blocks. Each block is transformed from the spatial domain (pixel brightness values) into the frequency domain using the Discrete Cosine Transform. The DCT does not discard any data — it is a perfectly reversible mathematical transformation. What it does is rearrange the information so that the most visually important content (low-frequency patterns — smooth gradients and broad color areas) is concentrated in a few coefficients, while the least important content (high-frequency patterns — fine textures and sharp edges) is spread across many smaller coefficients.

After the DCT, each 8 by 8 block is represented by 64 frequency coefficients arranged from low frequency (top-left corner, called the DC coefficient) to high frequency (bottom-right corner). For a typical photographic block, most of the energy is concentrated in the low-frequency coefficients, and the high-frequency coefficients are small or zero.

Stage 4: Quantization — this is where the quality slider lives. Each of the 64 DCT coefficients is divided by a corresponding value from a quantization table and rounded to the nearest integer. The quantization table contains larger divisors for high-frequency coefficients (making them more likely to round to zero) and smaller divisors for low-frequency coefficients (preserving them more precisely). When you move the quality slider, you are scaling this quantization table. A higher quality setting uses smaller divisors, preserving more coefficients. A lower quality setting uses larger divisors, zeroing out more high-frequency detail.

This is the lossy step. Once a coefficient is rounded to zero, the detail it represented is permanently gone. The genius of the approach is that the coefficients most likely to be zeroed out correspond to fine textures and subtle edges that the human eye is least sensitive to — especially in the chrominance channels, which already have reduced resolution from subsampling.

Stage 5: Entropy coding. The quantized coefficients are further compressed using lossless Huffman coding (or arithmetic coding in some implementations). After quantization, many coefficients are zero, which creates long runs of zeros that compress extremely well. Lower quality settings produce more zeros, which means better entropy coding ratios, which is why file size drops dramatically even beyond what the removed detail alone would suggest.

What Happens at Different Quality Levels

Understanding the pipeline makes the behavior of the quality slider predictable.

Quality 100 uses the smallest possible quantization divisors. Almost all DCT coefficients survive with minimal rounding error. The file size is large — often only 20 to 30 percent smaller than the equivalent PNG — because very few coefficients are zeroed out and entropy coding has less to work with. Visually, the result is nearly indistinguishable from the original, but mathematically it is not identical (JPEG is always lossy; there is no truly lossless JPEG mode in the standard pipeline).

Quality 85 to 95 is the sweet spot for high-quality archival and professional work. The quantization is gentle enough that artifacts are invisible at normal viewing distances, but aggressive enough on high-frequency coefficients to achieve 5:1 to 10:1 compression ratios. The file size difference between 95 and 100 can be a factor of two or more, with no perceptible visual difference — this is the most efficient region of the quality curve.

Quality 70 to 85 is the standard range for web images. Artifacts begin to be theoretically detectable in controlled comparisons but remain invisible to casual viewers. Compression ratios of 10:1 to 20:1 are typical. This is the range where the quality-size tradeoff is most favorable for bandwidth-constrained delivery.

Quality 40 to 70 produces visible artifacts on close inspection — particularly mosquito noise around sharp edges, blocky patterns in smooth gradients, and color banding in subtle transitions. For thumbnails, background images, and contexts where the image will not be closely scrutinized, these quality levels are often acceptable and produce very small files.

Quality below 40 produces obviously degraded images. Block boundaries become visible, fine detail is obliterated, and color shifts appear in areas of subtle gradation. These settings are only useful for extremely bandwidth-constrained scenarios or when the image serves as a placeholder.

Why Different Images Respond Differently

A photograph of a forest canopy at quality 60 might look acceptable, while a screenshot of text at quality 60 looks terrible. The reason is frequency content. The forest photograph is dominated by organic textures with soft gradients — mostly low and mid-frequency content that survives quantization well. The text screenshot contains sharp, high-contrast edges at precise pixel boundaries — exactly the high-frequency content that quantization targets most aggressively.

This is why screenshots, diagrams, text overlays, and images with sharp geometric patterns degrade faster than photographs at the same quality setting. It is also why PNG (lossless) is the better format for these image types — the sharp edges compress well with PNG's DEFLATE algorithm but compress poorly and degrade quickly with JPEG's DCT quantization approach. For a detailed comparison of when to use which format, see our article on WebP vs PNG vs JPEG.

WebP Compression: The Same Idea, Better Execution

WebP's lossy compression uses the same conceptual approach as JPEG — transform to frequency domain, quantize, entropy code — but with meaningful improvements at each stage. WebP uses a block prediction model derived from VP8 video compression that adapts the transform block size (4 by 4, 8 by 8, or 16 by 16) based on image content, uses arithmetic coding instead of Huffman coding for better entropy compression, and applies a deblocking filter that reduces block boundary artifacts.

The practical result is that WebP at quality 75 typically matches JPEG at quality 85 in visual quality while producing files 25 to 35 percent smaller. Google's own compression study measured an average 25 to 34 percent reduction in file size compared to JPEG at equivalent perceptual quality.

WebP also supports lossless compression and transparency (alpha channel), making it a viable replacement for both JPEG and PNG in many scenarios. The main limitation is that Safari on iOS still cannot encode WebP through the Canvas API's toBlob and toDataURL methods — Safari can display WebP images but cannot create them client-side. Our image compressor detects this limitation at runtime and disables WebP output on unsupported browsers.

Compression in the Browser

The HTML Canvas API provides native image compression through its toBlob and toDataURL methods. Both accept a MIME type and a quality parameter between 0 and 1. Calling canvas.toBlob(callback, "image/jpeg", 0.8) produces a JPEG blob at quality 80. The browser handles the entire JPEG pipeline internally — color conversion, DCT, quantization, and Huffman coding — using optimized native code that runs significantly faster than any JavaScript implementation could.

This is how browser-based compression tools work without uploading your images to a server. The source image is drawn onto a canvas, and the canvas is exported at the desired quality level. The quality parameter maps directly to the quantization table scaling described above. The browser does not expose chroma subsampling controls or quantization table customization — these are fixed at reasonable defaults — but the quality parameter is sufficient for the vast majority of use cases.

Our image compressor uses this approach with a real-time preview: you adjust the quality slider and immediately see both the visual result and the output file size, so you can find the exact point where quality meets your needs while file size fits your budget. Everything runs locally in your browser — no image data is ever transmitted.

Practical Compression Strategy

For most web projects, a systematic compression strategy is more effective than compressing images one at a time. Start by ensuring images are served at the correct dimensions — an image twice as large as needed in each dimension is four times as many pixels and roughly four times the file size before compression even enters the picture. Our image resizer handles this step.

Next, choose the right format. Use WebP as the default for web delivery where browser support allows. Use JPEG as a fallback for broader compatibility. Use PNG only when you need lossless quality or alpha transparency. Our image format converter handles format switching.

Finally, apply lossy compression at quality 75 to 85 for photographic content and quality 85 to 95 for images with text, sharp edges, or fine detail. Inspect the result — if artifacts are visible at the intended display size, increase the quality. If the file is larger than needed and no artifacts are visible, decrease it. The goal is to find the lowest quality setting that produces no perceptible degradation at the intended viewing conditions.

The Bottom Line

The quality slider in any image tool controls quantization — how aggressively the frequency-domain representation of your image is rounded toward zero. Higher quality preserves more high-frequency detail at the cost of larger files. Lower quality produces smaller files by discarding detail that the human eye is least sensitive to. The sweet spot for web delivery is typically quality 75 to 85, where compression ratios of 10:1 to 20:1 are achievable with no visible degradation for photographic content. Understanding this tradeoff — and the DCT-quantization pipeline behind it — turns image compression from a guessing game into an informed decision.

References

Stanford — Lossy Data Compression: JPEG — Clear explanation of DCT and quantization in the JPEG pipeline.

Google — WebP Compression Study — Google's comparison of WebP vs. JPEG compression efficiency at equivalent perceptual quality.

MDN — HTMLCanvasElement.toBlob() — Documentation for the Canvas API's blob export method, including quality parameter behavior.

Wikipedia — Lossy Compression — Overview of lossy compression techniques across image, audio, and video formats.

Scanly — JPEG Compression Artifacts Explained — Visual guide to common JPEG artifacts and their causes at different quality levels.