Compress images

Reduce weight while preserving the image’s purpose

Compression succeeds when the receiving file is lighter and still communicates what matters. For a photo, the subject and texture may matter most. For a diagram, labels and connections may matter most. Begin with the least disruptive change: compare encoding at the required dimensions before discarding pixels. If the source is far larger than the display needs, a measured dimension reduction may be more useful than extreme low-quality encoding.

Compare the downloaded candidate with the original, not with another compressed candidate. The result can occasionally be larger because the original was already efficiently encoded. That is a useful measurement, not something to hide. If a maximum byte count is mandatory, use the dedicated size-limit tool and keep hard dimensions fixed unless the destination permits a reduction.

Pixels describe the image; bytes describe the file

A 1920 × 1080 image has 2073600 pixels, regardless of whether it is stored as JPEG, PNG or WebP. That count describes its decoded grid. The download’s byte count describes the compressed representation of that grid. A flat illustration and a grainy photograph can share the same dimensions while producing very different file weights. Texture, noise, alpha and encoding settings all change what the encoder has to store.

This distinction explains two common surprises. A smaller image can still weigh more after it is re-encoded with different settings. A tiny compressed file can still need substantial memory when decoded. Evaluate dimensions, stored bytes and visual detail separately. None of those measurements can stand in for the other two.

Quality is a control, not a percentage of perfection

A JPEG quality value of 85 does not mean that 85% of the source survives. It is an encoder setting, and its visual effect depends on the image and the encoder. Start with a moderate high-quality export, inspect important details, then lower the setting only as far as your use case allows. Skin, hair, small lettering, foliage and smooth gradients are useful places to look for artifacts.

Dimensions and quality solve different problems. A 4000 px photo at very low quality may contain lots of pixels but weak detail. A 1000 px photo at high quality may look clean at its intended size but cannot supply a large print. Choose a sensible pixel grid first; then use quality to control encoding. Even quality 100 is not a guarantee that a JPEG export is lossless.

Why a resized PNG can become heavier

Resizing changes pixel values along edges and gradients. A compact source may use a palette, while a browser export may use a fuller color representation. The original may also have been carefully optimized. Fewer pixels therefore do not guarantee fewer stored bytes. Compare the real source and output sizes rather than assuming a particular saving from the scale percentage.

Try the optional lossless optimizer when PNG is required. “Lossless” describes the optimization of the already exported PNG: it must preserve that image’s decoded pixels. It does not undo changes introduced by resizing, and it does not guarantee a smaller file for every input. If the optimized export is not smaller, retaining the valid native output is preferable to claiming a saving that did not happen.

Meet a byte ceiling without hiding the tradeoff

A maximum file size is an acceptance rule: the result must not exceed a ceiling. It does not require the output to weigh exactly that amount. This editor uses decimal units, so 100 KB means 100000 bytes and 1 MB means 1000000 bytes. A result of 98200 bytes meets a 100 KB limit; 100001 bytes does not. Those values explain the rule, rather than predicting what your photo will produce.

For JPEG and WebP, the tool can try different quality values. If the limit still cannot be met, a fit-mode job can reduce dimensions only when you explicitly allow that. Exact crop and padding canvases remain fixed. PNG follows a different path because its encoding is lossless here. An unreachable combination should lead to a clear warning and a revised requirement, not a secretly changed format or chopped-off subject.

The download is the final test

A preview is helpful, but the saved output is what the receiving app will use. Check its actual dimensions, MIME type and exact bytes. Open the file in an image viewer, inspect the important details at a sensible scale, and confirm that transparency or the chosen background behaves as expected. If you created a ZIP, open it and compare its successful entries with the expected count.

When a result fails, change the constraint that is actually responsible. Wrong shape calls for a geometry decision; unreadable text calls for more detail or less aggressive encoding; excessive bytes call for a permitted compression or dimension change. Keep each candidate separate until you choose the final one. The original remains your reliable starting point for every new export.

1. Check the real width and height, not only the requested box.
2. Compare exact bytes with the destination’s ceiling.
3. Inspect faces, lettering, product edges and transparent boundaries.
4. Save the chosen output and keep the original separately.