<!-- meta: Image compressor not working? Learn why resize-first order, format choice, chroma subsampling and target-size search actually shrink a photo. -->
<!-- slug: why-image-compressor-not-working -->
The slider is the last decision you make, not the first, and most of the bytes you are fighting were never the slider's to remove.
You have a product photo that needs to go on a landing page. The original is 6,000 pixels wide and weighs more than the page's entire JavaScript bundle. You open an online tool to compress image files, drag the quality slider down until the preview looks acceptable, export, upload, and it is still 900 KB. So you do it again, on the file you just exported. By the third pass the label edges are mushy and the file is barely smaller than after the first attempt.
That experience is the most common reason people conclude their compressor is broken. It almost never is. The problem is doing the right operation in the wrong order, on the wrong format, with settings that fight each other. A compressor can only remove what is left to remove after the structural decisions are made. Hand it a 6,000-pixel PNG with an embedded colour profile and you will still be shipping an oversized photograph to a browser that draws it 800 pixels wide.
Fixing this needs no expensive software. It needs the four decisions that actually control file size, made in the right sequence.
The short answer
Shrinking a photo is four decisions in a fixed order. Resize to the largest size the image is actually displayed at, because pixels you never show are bytes you never needed. Choose the container: JPEG or WebP for photographs, PNG only when you need genuinely lossless pixels or transparency. Strip the metadata you do not need, which costs nothing visually. Only then choose quality, ideally by searching for the lowest value that passes your own visual check rather than guessing.
Everything else follows: quality 100 to 85 feels almost free because the encoder discards detail eyes ignore, a PNG screenshot refuses to shrink because PNG preserves every pixel exactly, and re-compressing looks worse because lossy compression accumulates rather than stacks.
Get the order right and the slider becomes boring, which is the point.
Resize first, then compress: the order that matters most
Here is the mistake that wastes more quality than any other: compressing a 6,000-pixel image to a 100 KB budget, then displaying it in a 900-pixel slot.
Consider what the compressor is asked to do: preserve detail across six thousand pixels within 100 KB. That is a punishing budget per pixel, so it discards fine texture, softens edges, and introduces blocking. The browser then throws most of those pixels away when it scales the image down. You paid the quality cost at full resolution and discarded the benefit.
Resize first and the arithmetic changes. At 1,200 pixels wide, a 100 KB budget is comfortable. The encoder keeps real detail, gradients stay smooth, packaging text stays readable. The file looks better at the same size, because you gave the compressor a realistic job.
A practical rule: resize to roughly twice the CSS display width for high-density screens, capped at the source resolution. A hero image shown at 1,200 CSS pixels wants about 2,400 pixels of real data; beyond that you ship pixels no screen resolves. A 300-pixel thumbnail needs 600 pixels at most. When there are many files at once, a bulk image resizer handles the dimensions without a round trip through an editor.
Downscale from the original in one step where possible; repeated small resizes soften the image. Use a reasonable resampling filter, since nearest-neighbour produces jagged edges on photographs.
Why PNG screenshots are huge, and when PNG is the wrong format
A screenshot of a dashboard or a slide full of text often ends up as a multi-megabyte PNG. People assume the tool failed. It did not. PNG is lossless, storing pixel values exactly, and it does not use chroma subsampling, so every pixel keeps full colour resolution. A photograph of a forest contains millions of subtly different greens that compress poorly under those rules. A screenshot of flat text contains long runs of identical pixels, which PNG handles well, until you add a photo, gradient, or drop shadow and the file balloons.
PNG is right for transparency with clean edges, line art and text that would visibly degrade, exact pixel values for design assets, and files that will be edited again. It is wrong for photographs and photographic screenshots destined for a page where a lossy format would be indistinguishable.
The confusing case is a screenshot with text, because lossy compression produces ringing around sharp letterforms. A good PNG optimiser can still cut a surprising amount by removing metadata and recompressing pixel data more efficiently, without changing a single pixel. If you need to compress PNG without losing quality, look for that: lossless optimisation, not a quality slider.
The JPEG quality curve: the big wins are near the top
JPEG quality is not linear. It runs 0 to 100, but the visual difference between 100 and 90 is small while the size difference is large, and the difference between 60 and 40 is large while the saving is modest. That is why "just lower the quality" is bad advice and "lower it from 100" is good advice.
At 100 the encoder tries to preserve nearly everything, including fine noise nobody sees at display size. Dropping into the mid-to-high 80s discards that invisible detail and typically produces a much smaller file with no visible difference on a normal screen. It is the most reliable saving on a photograph, which is why experienced exporters set quality in the 80s and stop worrying.
Push lower and you enter a different regime. Somewhere below about 60, artefacts become structural: eight-by-eight blocks appear in smooth gradients, edges gain halos, fine texture turns to mush. For a photograph viewed full size that is usually unacceptable. For a blurred background behind text it may be fine. The useful question is not "what quality should I use" but "what is the lowest quality that still looks right where this will live".
Your preview window is a poor judge: it fits the image to your screen. Judge at 100 percent on the most detailed region, then again at final display size.
Chroma subsampling: why 4:4:4 loves text and 4:2:0 loves photos
Colour is stored as one luma channel and two chroma channels. Human vision is far more sensitive to brightness detail than to colour detail, so most photo formats store colour at lower resolution. That is chroma subsampling.
In 4:4:4 every pixel keeps its own colour. In 4:2:0 colour is stored at half resolution in both directions, cutting colour data to a quarter. For photographs this is nearly invisible, because colour changes slowly across skin, sky, and foliage; luma carries the detail your eye wants. For text and sharp coloured edges it is a disaster. A red letter on white has a hard colour boundary the encoder can no longer represent precisely, so you get colour bleed and fringing around glyphs.
This is why a JPEG screenshot can look worse than its file size suggests, and why the same compressor that flatters a portrait can ruin a UI capture. For text-heavy content, either use 4:4:4 and accept a larger file, or choose a different format.
WebP and AVIF handle sharp edges better at the same budget, but the principle stands: subsampling bets that colour detail does not matter. Right for photos, wrong for interfaces.
Metadata, ICC profiles and thumbnails are dead weight
A JPEG from a phone is not just pixels. It carries EXIF: camera model, lens, exposure, sometimes GPS. It may carry an ICC profile describing how colours should be interpreted, an embedded thumbnail generated by the camera, and XMP blocks or edit history.
None of that makes the photo look better in a browser, and all of it costs bytes. GPS coordinates in a published photo are also a privacy problem, which is reason enough to strip metadata even when the saving is small. An embedded thumbnail is a second, smaller copy travelling inside the file for no reason at all.
Stripping metadata is the one optimisation with no quality trade-off. Some tools do it by default; many preserve it because photographers want copyright and colour information intact. For web delivery, removing EXIF and the thumbnail is almost always correct. ICC profiles need care: if the image is wide-gamut, removing the profile can shift colours, so convert to sRGB first, then strip.
Why compressing twice compounds the damage
Lossy compression is not idempotent. Each pass re-encodes the output of the previous one, so the encoder approximates an approximation. Artefacts from the first pass become input for the second, and part of the budget goes into reproducing damage instead of the photograph.
The consequence is simple: never compress a file you already compressed. Need a different size or quality? Go back to the original. Keep originals in a folder you do not touch and treat exports as disposable. If a client sends a "small version" and asks for something smaller, request the original; re-compressing their export will look worse than compressing the source once.
The same applies to screenshots of compressed images, exports from chat apps, and previews downloaded from social platforms. Those have been through at least one lossy pass and sometimes several, so your quality ceiling is set by the worst file in the chain.
A subtler version: resizing an already-compressed image, then compressing again. Resampling softens, compression adds artefacts, and the second encode amplifies both. If the compressed file is all you have, encode once at a conservative quality and stop.
How to compress image to a target size (it's a search problem)
Most upload forms do not ask for a quality level. They ask for a maximum size: 200 KB, 500 KB, 1 MB. People respond by guessing, exporting, checking, and repeating until it fits. That works, but it is slow and usually overshoots or undershoots, leaving quality on the table or shipping something muddy.
The correct framing is that target-size compression is a search problem. File size rises monotonically with quality, so you can binary search: try a quality, measure, narrow the range. A few iterations land within a percent or two of the target, and a shell loop does it in seconds.
# Binary search JPEG quality to hit a target size (ImageMagick)
target=200000; lo=40; hi=95; src=photo.jpg
while [ $((hi - lo)) -gt 1 ]; do
q=$(((lo + hi) / 2))
magick "$src" -resize '1600x1600>' -strip -quality "$q" out.jpg
size=$(wc -c < out.jpg)
if [ "$size" -le "$target" ]; then lo=$q; else hi=$q; fi
done
magick "$src" -resize '1600x1600>' -strip -quality "$lo" out.jpgThe important part is not the loop. It is -resize and -strip before -quality, which is this article's argument in one command. With correct dimensions and no metadata, the search converges fast and beats a guessed value.
In Node, sharp exposes the same idea: resize, then .jpeg({ quality, mozjpeg: true }) or .webp({ quality }), checking .toBuffer() length in a loop. The API differs; the order does not.
| Format | Compression | Transparency | Best for | Watch out for |
|---|---|---|---|---|
| JPEG | Lossy | No | Photographs, hero images, product shots | Text and sharp edges; artefacts below moderate quality |
| PNG | Lossless | Yes | Logos, UI, line art, exact pixels | Photographs and gradients; very large files |
| WebP | Lossy or lossless | Yes | General web images, mixed content | Older tooling; some editors still awkward |
| AVIF | Lossy or lossless | Yes | Modern web delivery, small files | Slower encoding; support on older devices |
If you would rather not script it, a free image resizer handles dimensions, and a reduce image size in KB tool handles the target-size search.
WebP and AVIF beat JPEG at the same visual quality
At the same perceived quality, a modern encoder generally produces a smaller file than JPEG. That is not marketing; newer tools describe an image more efficiently. WebP borrows ideas from video compression, predicts blocks more cleverly, and supports transparency, which JPEG cannot do at all. AVIF goes further with a newer intra-frame codec that handles fine detail and gradients better, typically winning on size again at the cost of slower encoding.
The gap changes what you can afford. A photo that needs a painful JPEG quality to fit a budget can often ship as a comfortable WebP at the same size and look cleaner. Across an image-heavy site, that saving compounds on every page.
Support is the caveat, and it shrinks every year. Current major browsers handle WebP, and AVIF works in modern Chrome, Firefox, Safari, and Edge. Check your analytics: if a meaningful share of your audience is on old browsers or embedded webviews, serve a JPEG fallback through <picture>.
One caution: converting an already-compressed JPEG to WebP does not recover lost quality. Transcoding a damaged source preserves the damage. Convert from the original. For a container-by-container reference, MDN's image file type guide is worth bookmarking.
Upscaling never adds detail, and 1000 px often beats 4000 px
Two related misconceptions waste a lot of bandwidth.
The first is that upscaling improves an image. It does not. Enlarging a 1,000-pixel photo to 4,000 pixels produces more columns, but the information content is unchanged; the new pixels are interpolated guesses. AI upscalers make better guesses, and they can look impressive on faces and textures, but they invent plausible detail rather than recover real detail. For a product photo that is a liability, because the invention may not match the actual product. Upscale for print if you must, never to make a web image "higher quality".
The second is that a bigger file is a better web image. The browser draws your image into a box measured in CSS pixels. A 4,000-pixel file shown in a 500-pixel slot is scaled down, and the extra pixels are averaged away on a standard display. Meanwhile it costs several times the bytes and delays rendering.
This is why a 100 KB image at 1,000 pixels routinely beats a 300 KB image at 4,000 pixels. The smaller file was encoded at a comfortable bits-per-pixel ratio, so it kept clean edges; the larger one was squeezed to fit a budget and displayed small, so all anyone sees is the damage. Display size is the frame of reference. Encode for it.
FAQ
Why does my image get bigger after I compress it?
Usually an output format change. Saving a JPEG as PNG, or re-encoding with a different colour profile, can increase size despite the compression request. Check the extension and export settings.
Is it better to resize or compress first?
Resize first, always. Compression quality depends on how many pixels share the byte budget, so smaller dimensions give the encoder an easier job and preserve more visible detail.
How do I know what quality to use?
Judge at display size, not in a fit-to-window preview. Start high, step down until you can see a difference, then go back one step. With a hard size limit, binary search instead.
Why is my PNG screenshot so large?
PNG stores every pixel exactly and keeps full colour resolution, so photographic content and gradients compress poorly. For screenshots containing photos, a lossy or modern format will be far smaller.
Does compressing an image twice make it worse?
Yes. Lossy compression is applied to an already approximated image, so artefacts accumulate. Always re-export from the original rather than compressing a compressed copy.
What is chroma subsampling and should I care?
It stores colour at lower resolution than brightness. Fine for photos, bad for text and sharp coloured edges. If a screenshot looks fringed, subsampling is a likely cause.
Do WebP and AVIF really beat JPEG?
At the same perceived quality they usually produce smaller files. The gap is large enough to matter for image-heavy pages, but check audience support and keep a fallback if needed.
Does removing metadata change how the image looks?
Removing EXIF and thumbnails does not change pixels. Removing an ICC profile can shift colours, so convert to sRGB first, then strip.
Can AI upscaling make a small image usable?
It can make it look sharper, but the added detail is generated, not recovered. For product photography or anything where accuracy matters, that is a risk rather than a fix.
The bottom line
Your compressor is probably fine. What fails is the sequence around it. Resize to the size the image is actually displayed at, pick a format that matches the content, strip the metadata you do not need, and only then search for the lowest quality that holds up. That order turns an unpredictable fight with a slider into a repeatable process, and it explains every symptom people blame on bad tools: the PNG that will not shrink, the JPEG that looks smeared after three passes, the 4,000-pixel file that looks worse than the 1,000-pixel one.
The mental model to keep is that file size is a budget and pixels are what you spend it on. Spend pixels on display size, spend bytes on detail that survives, and refuse to pay for anything the viewer will never see.
No comments:
Post a Comment