Image Compressor & Resizer
Shrink and resize a JPEG, PNG or WebP right in your browser — it never leaves your device. Set the width or quality, or type a target size in KB and it finds the best quality that fits.
No image handy?
Lands at or under the target — as close as quality alone allows; dimensions are never touched. JPEG and WebP only: PNG is lossless and takes no quality knob, so for a byte budget switch to JPEG or WebP and accept some fine-detail loss.
Result
Drop or choose an image on the left and the compressed version shows up here — before → after size, the exact pixels, and a one-click download.
Your images never leave your browser. Decoding, resizing and re-encoding all happen on your own device with the Canvas API. There are no uploads, no logging and no analytics on this tool — you can disconnect from the internet and it still works.
Lossy vs lossless — what actually shrinks a file
Two levers control an image's size: how many pixels it has and how those pixels are encoded. Dropping the pixel count — a smaller max width or a lower scale — is usually the single biggest saving, because file size roughly tracks the pixel area, not the width. A 4000 px-wide photo resized to 1600 px keeps only (1600/4000)² ≈ 16% of its pixels, so it starts more than six times smaller before any quality tuning.
Lossy formats (JPEG and WebP) then discard the fine detail the eye is least likely to miss; the quality slider decides how aggressive that is. Lossless PNG keeps every pixel exactly, so it never degrades — but it also compresses photographs far less, which is why a photo saved as PNG often ends up larger than the JPEG you started with.
Worked example: a phone photo for the web
Take a typical 12-megapixel phone shot, 4000×3000 px, saved by the camera as a JPEG at roughly 4.2 MB. You want it for a blog post where it will display about 800 px wide. A representative path through this tool:
| Setting | Result | Notes |
|---|---|---|
| Original (4000×3000, JPEG) | ~4.2 MB | Far more pixels than the page needs |
| Max width 1600, JPEG q 0.80 | ~250 KB | Sharp on retina screens; ~94% smaller |
| Max width 1600, WebP q 0.80 | ~180 KB | Same look, ~28% under the JPEG |
| Max width 1600, JPEG q 0.60 | ~150 KB | Faint blocking in skies if you look |
Your exact bytes will differ with the photo's content — a busy landscape compresses less than a plain portrait — but the shape holds: resizing did most of the work, and the last push from quality 0.80 to 0.60 saves far less than the first resize did while costing visible quality. The before → after sizes here update the instant you move any control, so drag the quality slider until you see the artefacts, then back off one notch.
Compressing to a target size — how the KB mode works
When you type a number into Target size, the tool stops using the quality slider and searches for the right quality itself. JPEG and WebP encoders take a quality parameter from 0.01 to 1.00, and file size grows with it, so the search can bisect: encode at quality 0.51 — over the target? try 0.25; under? try 0.76 — halving the range each round. A 1–100 quality range needs at most 7 trial encodes, all on your own device, and lands on the highest quality that still fits. The result line shows the exact bytes achieved and the quality used, so nothing is hidden.
The guarantee is deliberately narrow and honest: at or under the target, as close as quality alone allows. Quality is the only knob the search turns — your dimensions stay exactly what Max width and Scale say. That also means a target can be genuinely unreachable: a 4000×3000 photo has too many pixels to fit in 30 KB at any quality. When even minimum quality overshoots, the tool tells you so in plain words instead of handing you an over-target file, and points you at the stronger lever — lower Max width or Scale first, then the same target usually becomes easy. Two caveats: the byte counts are real encodes, not estimates, so very large images take a moment; and PNG is excluded, because it is lossless and has no quality parameter to search — pick JPEG or WebP for a byte budget and accept that some fine detail is discarded.
JPEG vs PNG vs WebP
| Format | Compression | Transparency | Best for |
|---|---|---|---|
| JPEG | Lossy | No | Photographs; opens everywhere, even old software |
| PNG | Lossless | Yes | Logos, screenshots, line art, sharp text |
| WebP | Lossy or lossless | Yes | The web: ~25–35% smaller than JPEG at matched quality |
For the same visible quality, WebP is typically 25–35% smaller than JPEG on photos and, unlike JPEG, can store transparency. Every current browser displays WebP, so for anything web-facing it is usually the right pick. Choose JPEG only when a file must open in older desktop software or email clients that still don't understand WebP. Reach for PNG for logos, screenshots, line art and anything with sharp edges, text or an alpha channel — but never for photos, where its lossless encoding balloons the file.
Common mistakes
- Resizing up never restores detail. Enlarging a small image (scale above the source, or a max width bigger than the original) just interpolates new pixels from existing ones — it looks softer, not sharper. This tool only downsizes; it will not upscale past the source.
- Re-saving a JPEG stacks generation loss. A JPEG is already lossy; decoding and re-encoding it as JPEG adds a fresh round of artefacts on top of the old ones, so edges muddy even at the same quality number. Shrink by reducing dimensions, not by repeatedly re-saving.
- PNG is not a photo compressor. Saving a photograph as PNG usually makes it bigger, because millions of subtly different pixels defeat lossless packing.
- Quality 1.00 is rarely worth it. The jump from 0.85 to 1.00 can double the file for detail almost nobody can see. Around 0.75–0.85 is the sweet spot for most photos.
Honest limits
Everything happens on your own device through the browser's Canvas API and canvas.toBlob — no upload, no server, no analytics — so private photos, screenshots and scans stay in the tab. That same Canvas path strips all metadata: EXIF, GPS coordinates, camera settings and the embedded colour profile are discarded. That is usually a privacy win, but it means an image relying on EXIF orientation may appear rotated, and wide-gamut photos are treated as sRGB. It re-encodes with the browser's built-in encoder, so it does not run advanced optimisers like MozJPEG or a PNG palette-quantiser and will not beat a dedicated command-line tool byte-for-byte. Very large images (tens of megapixels) need a lot of memory to decode, animated GIFs are flattened to a single frame, and on a rare old browser without WebP encoding it falls back to PNG and tells you.