Image Compressor — Reduce JPG, PNG, and WebP Size

What compression actually trades away

Compression shrinks a file in 1 of 2 fundamentally different ways, and knowing which one you are using separates a 76% saving from a disappointing 5%. Lossy compression, the JPEG and lossy WebP approach, permanently throws away data the human eye is least likely to miss: it splits the image into 8x8 pixel blocks (64 pixels each), applies a discrete cosine transform to turn them into 64 frequency coefficients, and quantizes away the high-frequency detail in each block. Drop more and the file gets smaller but block edges and colour banding creep in. Lossless compression, the PNG approach, throws away nothing — it uses the DEFLATE algorithm (the same LZ77 plus Huffman coding as ZIP, from 1996) to record runs and back-references so the decoded pixels are identical to the original, all 24 or 32 bits per pixel intact, which is why a PNG screenshot stays razor sharp but rarely shrinks as far as a JPEG. WebP straddles both worlds — its lossy mode typically beats JPEG by 25–35% at the same visual quality, so a 60 KB JPG might land near 40 KB as WebP.

This tool exposes that trade through 2 modes across 3 formats, built on the browser-image-compression library, version 2.0.2, running in a background Web Worker thread, keeping the page responsive even with a 10 or 20 MB file. Balanced mode takes the lossy path with a target you control from 10% to 100%; High quality mode is the lightest re-encode the format allows, fixed at quality 1.0. Neither uploads your file — both decode and re-encode entirely on your machine, across 0 servers.

Why High quality mode is not truly lossless

Here is the honest caveat most compressors bury, stated plainly. This mode re-encodes your image through an HTML5 canvas at the maximum setting, 1.0. For a PNG that round-trip stays effectively lossless, because PNG stores exact pixels and re-encoding at maximum simply rebuilds the same DEFLATE stream. For a JPG the story differs: JPEG is a lossy format, so decoding it to pixels and re-encoding always discards a little more high-frequency detail, a phenomenon called generation loss. That is precisely why, in testing, this lightest setting still shrank a 154 KB JPG to 92 KB, a 40% reduction of 62 KB — a genuinely lossless operation could never remove 40% of an already-compressed 8-bit JPEG. The savings are real, the change is small, but it is not zero.

So the naming matters. We label it High quality, not Lossless, on purpose: it delivers the smallest visible change the tool can make, ideal when you want to trim a photo without a noticeable drop. But if you need a JPG returned byte-for-byte identical, the correct move is not to compress it here at all — re-encoding, even at quality 1.0 (100%), is by definition a change, a 2nd generation of the JPEG. For genuinely lossless work, keep the source as PNG or WebP lossless from the start.

Reading the numbers, and when the file grows

Balanced mode works from a size target derived from your slider: a 70% setting asks the encoder to aim for roughly 70% of the source size, and the library lowers JPEG quality across up to 10 iterations until it lands near that budget (with a 0.05 MB, 50 KB floor so tiny files are not mangled). In testing a detailed 252 KB photo dropped to just 60 KB at 70%, shedding 192 KB, a 76% saving, with no change visible at normal viewing size. Push the slider to 10% and the file shrinks past 90% but 8x8 block artefacts become obvious; hold it at 80–90% and savings are gentler but the image stays pristine. The 70–80% band is the sweet spot for web and email, typically 60–80% smaller with detail intact across the 0.1-to-1.0 range.

One honest limit: re-encoding an already-optimized image can produce a file larger than the input, because the encoder adds its own headers and cannot improve on work already done. This tool guards against that — if the compressed result would be bigger than your source, it keeps that source file and labels the row "already optimal" rather than handing you a heavier file. Resolution is preserved in both modes (nothing below 4096 px on the longest side is downscaled), so compression here changes bytes, not the pixel dimensions of a 1200x800 or 4000x3000 photo; to shrink a 4000-pixel photograph down toward 1080 or 800 pixels wide, reach for the dedicated resize tool beforehand, then compress the smaller result here for a compounding reduction.

Picking a quality target by purpose

Different destinations tolerate different amounts of loss, so the right slider position depends on where the image will live. For a full-width hero or blog header viewed on a large screen, 80% keeps gradients smooth and text crisp while still cutting most of the weight. For a product thumbnail shown at 300 px or a gallery grid tile, 65% to 70% is invisible at that display size and can halve the file again. For an email attachment where 25 MB is a hard limit, dropping to 50% turns a 6 MB batch into well under 2 MB. And for an archival copy you may edit later, use High quality and accept the smaller 10% to 20% saving in exchange for the least degradation. The single number on the slider maps directly to these outcomes, so treat 50, 65, 80, and 100 as 4 presets for 4 jobs rather than an abstract dial.

Why smaller images matter to your site speed

Images are usually the heaviest thing on any web page — often 50 to 60% of the total bytes — so they dominate the Largest Contentful Paint, the Core Web Vitals metric that measures how fast the main content appears. Google's LCP target is 2.5 seconds; a hero image trimmed from 500 KB down to 120 KB, shedding 380 KB, can shave 0.3 to 0.5 seconds off load on a 4G connection near 5 Mbps, which lowers bounce rate and helps search ranking. The practical recipe is boring and effective: export photos as JPG or WebP, run them at a 75% target, and ship the result. For a 20-image gallery, a batch pass averaging 70% smaller turns 10 MB of images into about 3 MB, saving 7 MB — all without a single file leaving the browser.

Quick reference

• Engine: browser-image-compression 2.0.2 in a Web Worker; canvas decode + re-encode.
• Formats: JPG, PNG, WebP (output keeps the input type).
• Balanced: size target from a 10–100% slider; 0.05 MB floor.
• High quality: quality-1.0 re-encode; lossless for PNG, near-lossless for JPG/WebP.
• Measured: 252 KB photo → 60 KB at 70% Balanced (76%); 154 KB → 92 KB in High quality (40%).
• Resolution: preserved (max 4096 px per side); this changes bytes, not dimensions.
• Growth guard: if output would exceed the input, your source file is kept instead.
• Privacy: 100% in-browser; images are never uploaded.