Image Compressor

Why is my compressed PNG barely smaller than the original?

PNG is already losslessly compressed by whatever tool exported it, and the compression ratio depends entirely on the image content. Photographs in PNG format compress poorly (typically 10–20% reduction) because every pixel carries unique noise that cannot be deduplicated; for photos you should convert to JPEG or WebP lossy instead. Screenshots, logos, and flat-color graphics compress well in PNG because of the large runs of identical pixels that oxipng's DEFLATE filters can collapse — expect 40–60% reduction on those. If your source is already from an optimized exporter like Figma or TinyPNG, there is often only a few percent left to squeeze.

Does compression degrade the image every time I run it?

For lossy formats (JPEG, WebP lossy) yes — every re-encode introduces new quantization artifacts because the encoder discards and re-approximates frequency data. Compressing an already-compressed JPEG at quality 85 will look slightly worse than the first compression even if the output file is a similar size; do your compression exactly once, from the original source, and archive the original. For lossless formats (PNG, WebP lossless) re-running the tool produces a bit-for-bit identical image every time because the pixel data is never approximated, only re-packed.

What is chroma subsampling and when should I change it?

JPEG encodes brightness and color in separate channels, and by default the color channels are encoded at half resolution in each direction (4:2:0 subsampling) because the human eye is much less sensitive to color detail than to brightness. For photos, 4:2:0 is fine and saves about 20% file size. For screenshots, infographics, or any image with saturated red or blue text on a contrasting background, 4:2:0 produces visible color fringing around the edges. Switch to 4:4:4 (full chroma resolution) for those cases — the file grows modestly but the text stays crisp.

Are my images uploaded to a server for compression?

No. The compression runs entirely in your browser via WebAssembly. When you drop a file onto the interface, it is read into the JavaScript heap via FileReader, passed to a Web Worker running the mozjpeg or oxipng WASM module, and the compressed output is handed back as a Blob you download directly. There is no fetch or XHR to any origin with the image bytes. You can verify in the browser devtools Network panel during compression — the only network requests should be the initial WASM module download (cached after the first visit) and standard page analytics that never see DOM or file contents.

Why does my image look worse on iPhone than on my laptop?

Almost always because you stripped the ICC color profile. Modern iPhones and recent MacBooks use Display P3, a wide color gamut that contains roughly 25% more colors than standard sRGB, especially in the reds and greens. An image saved with a Display P3 profile is interpreted correctly on those devices; strip the profile and the same pixel values are interpreted as sRGB, which desaturates and cools the colors visibly. Keep ICC profiles on anything photographic and only strip them for UI screenshots and graphics where color fidelity is irrelevant.