Image Compressor

PNG is a lossless format: it uses a variant of the DEFLATE compression algorithm to shrink the file, but decompressing it reproduces the exact original pixels, bit for bit, with nothing discarded. That's why a PNG has no quality slider — there's no quality to trade away, only how efficiently the same exact data gets packed, which is why PNG file size depends on resolution and image complexity, not a quality setting.

JPEG and WebP's lossy modes work fundamentally differently: they deliberately discard information a viewer is statistically unlikely to notice, based on models of human visual perception — subtle color gradations the eye is less sensitive to get simplified more aggressively than brightness detail, since human vision is more sensitive to changes in brightness than in color. Turning the quality slider down discards more of that perceptually-less-important detail in exchange for a smaller file; turning it up keeps more of it.

JPEG compresses by breaking an image into small blocks and re-expressing each block's content as a combination of frequency patterns (a discrete cosine transform), then discarding the higher-frequency components that contribute least to how the block looks. That approach works well for photographs, where color naturally shifts smoothly across an image, but it works poorly for sharp, high-contrast edges — exactly what text, logos, and flat-color icons are made of — producing the visible fuzzy halos and blocky artifacts you'll notice around text in a heavily compressed JPEG.

This is precisely why PNG remains the right choice for screenshots, icons, and anything with sharp edges or a small number of flat colors, even though it's often a larger file for a photograph than an equivalent-quality JPEG: PNG's lossless compression has no trouble representing a large flat region or a crisp edge exactly, while JPEG's frequency-domain approach is specifically tuned for photographic content and shows its weaknesses exactly where flat graphics live.

WebP is a newer format that supports both a lossy mode (generally producing smaller files than JPEG at a comparable visual quality, using more modern prediction techniques than JPEG's decades-old approach) and a lossless mode that can beat PNG's file size on many images — plus, unlike JPEG, WebP supports an alpha channel for transparency, which used to force a choice between JPEG's smaller size and PNG's transparency support. That combination is why WebP has become a common default recommendation for web images: it can replace either JPEG or PNG depending on which mode is used, usually at a smaller file size than either.

The main practical caveat is compatibility with older tooling and some image-editing workflows that don't fully support WebP yet — which is exactly why this tool, and most modern image pipelines, still offer JPEG and PNG as explicit output options rather than only producing WebP.

Images are very often the single largest assets a browser has to download to render a page, and on most content-heavy pages the largest image is also the Largest Contentful Paint (LCP) element — one of Google's three Core Web Vitals, and a metric that's both directly measured in Search Console and used as a ranking signal. A 3 MB hero image where a well-compressed 300 KB version would look identical to almost every visitor isn't just wasting bandwidth; it's directly inflating one of the specific numbers Google's crawler and real-user monitoring both track.

This is what makes image compression one of the highest-leverage, lowest-effort web performance fixes available: unlike restructuring a render-blocking script or fixing layout shift, cutting an image's file size in half typically requires no code changes at all, just choosing the right format and quality level for that specific image's content.

A quality slider only controls compression artifacts at a fixed resolution — it does nothing about an image that's simply larger in pixel dimensions than it needs to be for where it's displayed. A 4000×3000 photo straight off a phone camera, displayed at 800×600 in a web page, is wasting the vast majority of its file size on pixel detail no visitor will ever see rendered that small; resizing it down to roughly the display size first, before any quality compression, is usually a far bigger size reduction than tweaking the quality slider on the oversized original.

This is exactly why this tool exposes a max-width control alongside quality: the two solve different problems. Quality trades visual fidelity for file size at a fixed resolution; resizing removes pixel data the display genuinely can't show in the first place. Getting the resolution right before compressing is normally the single biggest lever on final file size, with quality adjustments a secondary refinement on top of an already-appropriately-sized image.