The Image Compressor and Resizer shrinks images where they live, in your browser: load an image, set target dimensions and an export quality, and download a smaller file in the format you choose, without uploading anything to a server. It is built for the everyday jobs that decide page speed and upload limits: product photos, blog heroes, marketplace listings, and form attachments with a size cap.
How It Works
Resizing fits your image inside the target box while preserving aspect ratio: the scale factor is the smaller of the width and height ratios, so neither dimension exceeds its target and nothing is stretched. Compression then re-encodes the pixels at your quality setting. The tool estimates the resulting file size from the pixel-count reduction and the quality level, using a model where size scales with pixel area times a quality factor, so you can see the expected saving before exporting.
Parameters
| Input | Required | Meaning | |---|---|---| | Image | Yes | The file to process, handled locally | | Target width and height | No | The bounding box for the resized output | | Quality | No | 1 to 100 encoding quality (default 80) | | Format | No | Export format offered by the tool (JPEG, PNG, or WebP) |
Worked example
A 4000 x 3000 phone photo of about 6,000 KB is fitted into a 1200 x 1200 box. The scale is the smaller ratio, 1200/4000 = 0.3, giving 1200 x 900 output. Pixel count falls to 9% of the original, and at quality 80 the size model estimates about 459 KB, a saving above 90% with dimensions still ample for a full-width web image. Push quality to 60 and the estimate drops further, at the price of visible softness in skies, skin, and gradients, which is the trade the preview exists to judge.
Resizing beats compressing, almost always
File size is driven first by pixel count. Halving width and height quarters the pixels, a saving no quality slider can match, and most images are displayed far smaller than they are captured. The right order is: resize to at most the largest display size (twice the display size for retina screens is a generous ceiling), then choose format, then tune quality. JPEG suits photographs without transparency; WebP usually beats JPEG by a further quarter to a third at equal quality; PNG is for transparency, text, and line art, where lossy formats smear edges, and it will always be the heavy option for photos.
Quality settings without superstition
Quality numbers are encoder-relative, not percentages of fidelity. For photographic JPEG and WebP, 75 to 85 is the standard production band: below 70, artifacts appear in gradients and around text; above 90, file size balloons for gains most viewers cannot see. Judge at 100% zoom on the actual problem areas of your image (edges, faces, sky), not on the whole-image thumbnail, and remember every re-save of a lossy image degrades it further, so always compress from the original, never from a previously compressed copy.
Limitations
The size figure is an estimate from a model, not a promise: busy, noisy photos compress worse than smooth ones at identical settings, and the exported file is the authority. Processing happens on your device, so extremely large images are bounded by browser memory. The tool does not crop, rotate, strip metadata selectively, or convert colour profiles, and it cannot recover detail that resizing discards.
Frequently Asked Questions
Does compressing reduce image quality permanently?
Lossy compression discards information permanently in the exported file, but your original is untouched; the tool processes a copy in the browser. Keep originals archived and export per use case.
Why is my PNG still huge after compression?
PNG is lossless and photographic content defeats it. For a photo without transparency, exporting as JPEG or WebP at the same dimensions will usually cut the size by 70% or more.
What dimensions should I use for a blog image?
Match the display: a content column of 800 CSS pixels wants about 800 to 1,600 image pixels wide (the upper end for retina). Larger only adds weight that no screen will ever show.