Compressing Images Without Wrecking Them

The single most useful thing I learned while building Toolium's image compressor was this: most of the photos people upload are already compressed, and trying to compress them again either does nothing or makes them visibly worse. If you take a photo with a modern phone, the camera pipeline has already run JPEG encoding at a quality setting between 80 and 95. By the time the file lands on your computer, the per-pixel information has already been quantized, the chroma channels have already been subsampled, and the entropy coder has already squeezed out the redundant bits. Running that same image through a second round of compression at the same quality level is basically a no-op; running it at lower quality just exposes the artifacts that were already there.

The original version of the Image Compressor did not know any of this. It would happily produce an "output" file that was 2% smaller than the input, or sometimes a tiny bit larger because of overhead from the re-encoding. The fix - and this is the version on Toolium now - is to compare the output to the original and keep whichever is smaller. If you upload an already-optimized JPEG, you get your original back, and the tool tells you it could not improve on the source. This is more honest and saves a lot of confusion.

Two kinds of compression, with totally different math

The word "compression" covers two operations that work in fundamentally different ways:

Lossless compression reduces file size without changing a single pixel value. The output looks bit-for-bit identical to the input when decompressed. PNG is the obvious example - the format uses deflate (the same algorithm zip uses) on the pixel data, plus some preprocessing filters that help the deflate stage. There is no quality slider for lossless compression because the quality is identical to the source.

Lossy compression reduces file size by selectively discarding information that the encoder considers visually unimportant. JPEG, WebP, and modern formats like AVIF are all lossy. The quality slider is the lever that controls how much information gets discarded. At quality 100, almost nothing is discarded (and JPEG output is large). At quality 1, most of the high-frequency detail is discarded (and JPEG output looks like blocky garbage). The interesting range, for photographs, is roughly 70 to 90.

For typical photos at typical viewing sizes, the threshold where JPEG compression becomes visible to a human is around quality 75. Above that, the differences are subtle enough that you have to look hard. Below that, the artifacts start to be visible in flat areas like skies and skin. The Image Compressor defaults to a target size (a fraction of the original file size, which translates internally to a quality level) rather than a quality number directly, because most people care about the resulting file size more than the abstract quality dial.

Why compression sometimes makes the file bigger

This catches everyone the first time. You compress a 200 KB PNG screenshot at "high compression" and the output is 215 KB. What happened?

Two things, usually. First, PNG is already lossless, so the input has no "extra" data to throw away. The output is being re-encoded through the canvas API, which adds a small amount of overhead in the way it represents the pixel data. Second, the canvas API does not round-trip PNGs perfectly - it normalizes color profiles, strips chunks the browser does not understand, and re-runs the deflate compression. Sometimes the re-deflated stream is slightly larger than the original.

For this case, the tool falls back to keeping the original. You should never end up with a larger file than you started with. If you do, please email me because it is a bug.

The transparent-PNG-to-JPEG trap

This is the single most important bug I have fixed in the image tools, and I am going to describe it in detail because the same trap exists in almost every browser-based image converter.

JPEG cannot store transparency. PNG can. If you take a transparent PNG (say, a logo with no background) and re-encode it as JPEG, the encoder has to do something with the transparent pixels because the JPEG format does not have an alpha channel. The canvas API's default behavior is to initialize the canvas backing buffer to transparent black (RGB = 0,0,0, alpha = 0). When you draw your transparent PNG onto that canvas and then export to JPEG, the transparent pixels get filled with the underlying black. Your nice logo ends up on a black rectangle.

The fix is to fill the canvas with white before drawing the image. Most users expect a transparent-to-JPEG conversion to produce a white background, because that is what every desktop tool does. Toolium does this now, but it took a few weeks of confused user reports before I figured out what was happening. If you ever use a different free image converter and your converted logos come out on a black square, this is what is happening.

WebP, AVIF, and the format question

People ask me a lot whether they should be converting their JPEGs to WebP. The answer is: usually yes, if you are using them on the web, but the math depends on your use case.

WebP at quality 80 produces a file about 25 to 35 percent smaller than JPEG at quality 80, with visually indistinguishable output. Browser support is now universal - even Safari, the last holdout, has supported WebP since 2020. For images you serve on a website, WebP is the right default.

For images you email, attach to documents, or share with non-technical people, JPEG is still the safer bet because some older email clients and document apps do not handle WebP gracefully.

AVIF is the next generation - even smaller files at the same visual quality, but encoding is slower and not every browser supports it for input yet. I am not yet using AVIF in the Toolium converter because browser support for AVIF encoding via the canvas API is still patchy. For now, WebP is the modern sweet spot.

The actual recipe for compressing well

When someone asks me how to compress a folder of photos for a website, the workflow I recommend is:

1. Resize first. If you have 4000-pixel photos and you are going to display them at 1200 pixels, resize first. Most file size comes from pixel count, and the math is roughly squared - halving the dimensions cuts the file size by 4x. Use the Image Resize tool for this.
2. Convert to WebP if it is web-bound. Use the Image Format Converter. WebP at quality 80 is the modern default.
3. Compress to a target size if you have a specific budget. The Image Compressor takes a target fraction (0.5 = half the original size) and produces output close to that.
4. Spot-check the result on a real device, ideally a phone screen. Compression artifacts that are invisible on a desktop monitor sometimes show up on a high-DPI phone display, and vice versa.

Doing these in this order, rather than just compressing the original 4000-pixel photo at low quality, is the difference between a sharp, small image and a blurry one. The compression algorithm cannot make up information that is no longer there, so reducing dimensions first preserves more visual quality at any final file size.

Privacy and the absent server

The compressor runs entirely in your browser. The library doing the heavy lifting is called browser-image-compression; it uses the canvas API plus a small wrapper that handles batch processing and the kept-original fallback. There is no upload step. If you compress a folder of personal photos, the originals stay on your computer; only the compressed copies download to your downloads folder. This is the same architecture as PDF Merge and every other Toolium tool - everything is documented on the methodology page.

Common errors and what they mean

• "Compression did not reduce the file size." Your input was already optimized. The tool kept the original. This is a feature, not a bug; you cannot reliably make an already-compressed JPEG smaller without visible quality loss.
• "Out of memory." You uploaded a file larger than the browser can hold in memory, usually a multi-hundred-megapixel image from a professional camera. Resize before compressing, or split the batch into smaller groups.
• "Format not supported." The tool accepts PNG, JPG, and WebP. GIF, SVG, BMP, and HEIC are rejected up front. HEIC is the one that surprises iPhone users; convert it to JPG on the phone first (the Files app can do this) or change your camera setting to "Most Compatible" instead of "High Efficiency."
• "Output has wrong format." The output format matches the input format. If you upload a PNG, you get a PNG back. To change format and compress simultaneously, convert with the Format Converter first.