Skip to content

Image Compressor

Drop an image or click to browse

Runs in your browser — nothing is uploaded.

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

Compressing images for the web is the single biggest performance win for most pages — typical product photos and hero images can shrink 60-80% with no visible quality difference at normal viewing sizes. This tool runs entirely in your browser via Canvas API, with a live quality slider so you can see the size-vs-fidelity trade-off in real time.

How compression works

The image is decoded to a bitmap, drawn onto a canvas at original dimensions, then re-encoded with canvas.toBlob(mime, quality). The browser’s encoder (libwebp / libavif / Skia’s JPEG) handles the actual lossy compression — quantising DCT coefficients, predicting blocks, packing entropy-coded streams.

Lower quality = coarser quantisation = smaller files with more visible artefacts (blocking on smooth gradients, mosquito noise around edges). Most photographs tolerate quality 70-85 with no visible degradation when viewed at typical sizes.

Format guidance

SourceRecommendWhy
JPEG photoJPEG 75-85Same format, drop quality. Round-trip artefacts compound but mild.
JPEG photoWebP 75Smaller than JPEG-equivalent quality by 25-35%.
PNG screenshotWebP-lossy 85PNG is huge for screenshots; WebP shrinks by 5-10×.
PNG with transparencyWebP 85 (preserves alpha)JPEG can’t carry alpha — would need white background.
Any photoAVIF 65-75Smallest at equivalent quality. Slow to encode. Browser support varies.

Example: shrinking a camera JPEG

A 4 MB JPEG straight off a phone camera, compressed to JPEG at 80% quality, lands at ~900 KB — 4× smaller with no visible difference at full screen on a typical monitor. Same image to WebP at 75 → ~620 KB. To AVIF at 70 → ~440 KB.

Example: PNG screenshot for a blog

A 1.8 MB PNG screenshot of a UI. Compress to WebP at 90% (preserves the sharp text edges) → ~210 KB. PNG → WebP-lossy is one of the biggest compression wins available — PNG’s lossless overhead is enormous for screenshot-style content.

Example: reaching an upload limit

You need a JPEG under 1 MB for a job application form. Source is 3.2 MB. Drop quality to 70 → 950 KB. Done. The live slider makes this kind of “find the quality that hits the limit” workflow tight — nudge until size is right, download.

When compression isn’t the right tool

  • Source is already optimised. A WebP at 75 from a modern image pipeline is hard to compress further without visible loss. The tool will tell you if the file grew.
  • You need lossless output for editing. Use the format converter to switch to PNG (lossless) instead.
  • You need to resize as well as compress. Use the resizer first (or use a tool that combines both — this one preserves source dimensions).
  • You need to preserve metadata. Canvas re-encoding strips EXIF, IPTC, mostly ICC.

Common mistakes

Compressing PNG to PNG and getting a bigger file. As noted in the FAQ, canvas-encoded PNG goes through libpng defaults that are usually weaker than the source. PNG to PNG via canvas is almost always wasted effort.

Cranking quality to 100% expecting “no loss”. JPEG at 100 is still lossy — and ~3× bigger than the same image at 92. The 90-95 range is the sweet spot for “no visible loss.” 100 is rarely worth the extra bytes.

Re-compressing the same JPEG repeatedly. Each re-encode adds artefacts. If you’ll need to edit the image later, keep a lossless copy (PNG or WebP-lossless) as the master and re-derive the lossy distribution copy from that.

Forgetting that visual quality is content-dependent. Photos of texture / nature compress more aggressively than UI mockups with sharp edges. Test on representative images before deciding on a project-wide quality setting.

Comparing the size shown here against what your OS reports. macOS uses decimal MB (1 MB = 1,000,000 bytes); Windows uses binary “MB” (really MiB, 1,048,576 bytes per “MB”). Same file, ~5% different number. The data-size converter translates between the two.

What this tool does not do

It doesn’t resize. Source dimensions are preserved. Combine with the image resizer for both operations.

It doesn’t batch-compress. One file at a time. For large batches, use a build-pipeline tool like sharp or squoosh-cli.

It doesn’t support PNG output. Canvas-encoded PNG rarely shrinks the source. Pick a lossy target — or use the image format converter to switch to a more compressible format first.

It doesn’t upload anywhere. All compression runs in the browser via Canvas API.

Frequently asked questions

Why doesn't this compress PNG?

PNG is already lossless — `canvas.toBlob('image/png')` re-encodes through libpng's defaults, which are usually weaker than the source PNG's compression settings. So compressing a PNG via canvas typically produces a *bigger* file. The fix: pick a lossy target format (WebP, JPEG, AVIF) — those will shrink a PNG significantly. The tool warns you when the source is PNG and steers you toward a lossy target.

What's the difference between this and the format converter?

Same underlying canvas pipeline, different intent. The format converter is for changing format (PNG → WebP, JPEG → AVIF, etc.) and shows source vs target format prominently. The compressor is for shrinking a file in *the same format you'd ship it as*: re-encoding a JPEG at lower quality to fit an upload limit, or converting one big image to one smaller WebP. The compressor recommends a sensible default target based on source type and runs live as you adjust the slider.

How does the quality slider work for each format?

JPEG quality is a 0..1 number that controls quantisation table aggressiveness — lower means coarser blocks, more visible artefacts, smaller files. 92 is the Chromium default; 80-85 is fine for web display; below 50 becomes obviously lossy. WebP uses a similar 0..1 dial mapped to libwebp's quality parameter; same intuitions apply, but WebP at 75 typically beats JPEG at 85 for the same file size. AVIF compresses hardest — AVIF at 60-70 often matches JPEG at 85 in apparent quality, with files 30-40% smaller.

Why does the file sometimes get bigger when I compress it?

Because lossy compression is heuristic — at very high quality (95+) the encoder spends most of its bits on faithful reproduction, and if the source is already efficiently encoded (a clean JPEG from a modern camera, say) the new encoder may not match the source's bit allocation. The tool surfaces this as 'File grew by X%' rather than silently producing a worse file. Solution: drop the quality slider until savings turn positive.

Will this strip EXIF metadata?

Yes, by default. Browsers' canvas re-encode pipeline drops EXIF, IPTC, and (usually) ICC color profile metadata. For users this is mostly a feature: GPS coordinates and camera serial numbers don't leak when you compress and upload an image. If you depend on metadata (preserving timestamps for archival, retaining color profile for print), use a metadata-aware tool instead — the canvas re-encode path will erase it.