Image Compression in Practice: From 3.2 MB to 412 KB Without Visible Quality Loss

Why I did this test

Every image compression tool I've seen gives you a quality slider from 0 to 100 and leaves you to guess what that means. The slider is meaningless without reference points. Is 75 good? Is there a visible difference between 70 and 80? At what point does the file-size savings become negligible compared to the quality cost?

I had a batch of product photos — raw exports from a DSLR, mostly JPEG, some shot in RAW and converted to TIFF before export. The originals ranged from 2.1 MB to 5.8 MB. My target was a web-ready image under 500 KB that I couldn't visually distinguish from the original at full screen on a 1080p monitor.

I ran 60 images through the browser-based image compressorat six quality settings (90, 80, 75, 70, 60, 50) and recorded the output sizes and my subjective quality assessments. Here's what I found.

The raw numbers

I grouped the 60 images into three categories by source: DSLR product shots (high detail, warm colors), UI screenshots (text-heavy, flat colors), and landscape photos (natural gradients, complex backgrounds). The behavior varies significantly between these categories.

DSLR product shots (20 images, avg. original: 3.8 MB)

UI screenshots (20 images, avg. original: 1.1 MB)

Screenshots behave differently from photographs. JPEG's DCT compression is designed for natural images with gradual color transitions. Hard edges — like black text on a white background — show compression artifacts at lower quality settings than photographs do. For screenshots, I stop at quality 80. For photos, 75 is the sweet spot.

The quality setting sweet spot: 75 for photos, 80 for screenshots

After looking at all 60 images side-by-side at 100% zoom on a calibrated monitor, my conclusion:

• Photos (DSLR, product shots, portraits): Quality 75 is the crossover point. At 75, you get 86% file size reduction with no visible loss on a standard 1080p display. At 70, you save another 3% but risk visible degradation in out-of-focus areas (bokeh, soft backgrounds). Not worth it.
• Screenshots and UI captures:Stop at 80. The text fringing that appears at 75 is subtle but real, and your users will notice if they're reading documentation or looking at interface instructions.
• Thumbnails and small images (under 400px wide): Quality matters less at small sizes because the display resampling masks compression artifacts. 70 is fine here.

JPEG vs WebP: the actual difference

WebP is often presented as straightforwardly better than JPEG. The reality is more nuanced. I converted 20 of my DSLR shots to WebP at equivalent perceptual quality and measured:

• WebP at quality 75 produced files averaging 287 KB — about 46% smaller than JPEG at quality 75 (532 KB) for the same perceptual quality.
• WebP at quality 80 produced files averaging 374 KB — still 47% smaller than JPEG at 80.
• The savings are real and consistent. If your audience is on modern browsers (Chrome, Firefox, Edge, Safari 14+), WebP is the right choice.

The one case where I still use JPEG: images that need to be attached to emails or shared outside a browser context. WebP isn't supported by most email clients, Slack (as of early 2026), or Windows Photo Viewer on older machines. JPEG is the universal format; WebP is the web-optimized format.

What the quality slider actually controls

JPEG compression works by dividing the image into 8×8 pixel blocks, applying a Discrete Cosine Transform (DCT) to convert each block into frequency components, and then quantizing those components — discarding high-frequency detail that the human eye is less sensitive to. The quality setting controls the quantization table: lower quality means more aggressive quantization, meaning more detail is thrown away in each block.

This is why JPEG compression causes blockiness (the 8×8 grid becomes visible) and ringing (a halo around hard edges) when quality drops too low. The ringing artifact is particularly visible around text, which has sharp black-to-white transitions that DCT handles poorly.

WebP uses a different approach (transform coding based on VP8 video compression), which handles hard edges better and produces cleaner results at the same file size. That's the fundamental reason WebP outperforms JPEG for screenshots.

The point of diminishing returns

Going from quality 100 to 90 cuts file size by ~60–65% with no visible difference. That's a massive gain for free. Going from 90 to 80 cuts another 40–50% — still essentially free. Going from 80 to 75 cuts another 20–25% — usually safe. Going from 75 to 70 cuts another 15–20% — starting to risk quality. Below 70, the savings per quality point drop sharply while the visual damage increases.

The curve is not linear. Most of the savings come from the first 25 points (100 → 75). After that, you're fighting for small percentages while degrading the image meaningfully.

Metadata: the invisible overhead you should strip

JPEG files can carry Exif metadata embedded by the camera: GPS coordinates, camera model, lens data, shooting settings, copyright tags, and sometimes even a thumbnail preview of the full image stored inside the file. This metadata can add 40–120 KB to a photo that is otherwise 400 KB — a 10–30% overhead that contributes nothing visible.

The browser-based compressorstrips Exif metadata during compression by default (re-encoding the image drops the metadata since it's not part of the pixel data). For a batch of 20 product photos, stripping metadata alone saved an average of 78 KB per image before any quality reduction was applied.

One important note: if you're a photographer publishing images you want copyright- protected, check whether metadata stripping removes your copyright tag. For web publishing where images will be indexed by Google, the IPTC copyright field in Exif doesn't affect legal protection — your copyright exists at the moment of creation — but you may want to keep it for attribution purposes.

Progressive JPEG: worth it?

A regular JPEG loads top-to-bottom as bytes arrive. A progressive JPEG loads in passes — first a blurry version of the whole image, then progressively sharper versions. Progressive encoding often produces slightly smaller files (typically 5–15% smaller than baseline for large images) and looks better during loading on slow connections.

For images over 10 KB displayed on pages where users might experience slow loads (mobile, international traffic), progressive JPEG is worth the 2% file size increase that some encoders add when generating the progressive scan tables. The image compressor outputs progressive JPEG by default for files over 20 KB.

When browser-based compression isn't enough

The browser-based approach works well for one-off images and small batches. Here's where it falls short:

• Batch processing hundreds of images. The browser processes one image at a time. For 500+ image batches, a CLI tool like sharp (Node.js) or imagemin in a build pipeline is the right solution.
• AVIF encoding.AVIF (AV1 Image File Format) is the next-generation format after WebP, with 20–30% better compression at equivalent quality. Browser- based AVIF encoding is slow (it's computationally expensive) and not universally supported in browsers as an encoder. AVIF works better as a server-side build step.
• Lossless PNG compression. PNG files can be compressed losslessly (no quality loss at all) using tools like pngquant (which actually uses lossy palette reduction, despite the name) or oxipng(truly lossless zopfli compression). The browser Canvas API that powers most browser-based compressors doesn't give you access to these optimizations.

My actual workflow

For web publishing: drag image into the compressor, set quality to 75 (photos) or 80 (screenshots), choose WebP if the destination is a web page, JPEG if the file needs to be emailed or shared. Download. Done in under 10 seconds per image.

For product photography specifically: I do one round of browser compression to get a web-ready version, then keep the original uncompressed TIFF for print or re-editing. Never compress the master. The browser tool is for the delivery copy, not the archive.

Related tools

• Image format converter — convert between JPEG, PNG, WebP, GIF, and BMP without quality loss in the conversion step itself.
• Image resizer — reduce dimensions before compressing. A 4000×3000 image scaled to 1200×900 and then compressed at quality 80 will be far smaller than the same image compressed at quality 50 without resizing.

Written by Achraf A., founder of TheFreeAITools — built in Morocco. Test images were product shots and UI captures from real projects; no synthetic test images. Tested using the browser compressor on Chrome 124, macOS Sonoma.