Skip to main content

Image Compressor

Compress images by adjusting quality to reduce file size without losing visual clarity.

Reviewed by · Last reviewed

🖼️

Drop an image here or click to upload

Supports JPG, PNG, WebP

How to Use the Image Compressor

  1. Drop a JPEG, PNG, or WebP into the upload zone. The tool reads the file through the File API and shows the original size so you can measure savings.
  2. Drag the quality slider. Values run from 1% (heavy compression, visible artifacts) to 100% (virtually lossless re-encode). Around 75% is the sweet spot for photos; 50% is fine for chat screenshots.
  3. Pick an output format: JPEG for maximum compatibility or WebP for roughly 25-35% smaller files at the same visual quality.
  4. Watch the live preview. The output size and percent reduction update immediately so you can dial the slider until you hit your target budget.
  5. Download the compressed file. It is exported via canvas.toBlob(mimeType, quality) and offered through a blob URL - no network round trip.

What Compression Actually Does

JPEG compression is the original reason we can share photos on the web. The algorithm converts each 8x8 block of pixels to YCbCr color space, runs a Discrete Cosine Transform on each block, then quantizes the frequency coefficients more aggressively for the higher-frequency components that the human eye is less sensitive to. A lower quality slider value simply uses a more aggressive quantization table, throwing away more of those high-frequency details. That is why JPEG artifacts always look like fuzzy blocks around hard edges - those edges have high-frequency content the quantizer collapsed to zero.

WebP, specified by Google in RFC 9649, uses either VP8 intra-frame prediction (lossy mode) or its own lossless predictor-plus-Huffman pipeline. On typical photos WebP beats JPEG by roughly 25-35% at equivalent perceived quality, with the bigger win on low-quality settings where blockiness is more noticeable. The browser exposes both via canvas.toBlob('image/webp', 0.75), where the second argument is the quality hint the encoder uses to pick its quantization.

Where File-Size Savings Matter

  • Getting a product page's hero image below 200 KB so Largest Contentful Paint stays inside the 2.5-second Core Web Vitals threshold.
  • Emailing a batch of vacation photos to a family member whose inbox rejects attachments over 25 MB.
  • Stuffing more screenshots into a 100 MB Slack file-upload limit without resizing them.
  • Publishing a long-form blog post with twenty embedded images that still loads quickly on a mobile carrier in a marginal-signal area.
  • Cutting monthly CDN egress bills when your traffic grows past the free tier on Cloudflare or Bunny.
  • Archiving a photo library onto a 256 GB laptop SSD without moving everything to cloud storage.

Compression Gotchas

  • Re-encoding an already-JPEG file always loses quality. Even at 95% quality, the DCT pipeline runs again and stacks new artifacts on top of the existing ones. Compress once from the source, never repeatedly.
  • PNG to JPEG conversion flattens transparency. JPEG has no alpha channel - transparent pixels become white in the exported file. Use WebP if you need transparency plus compression.
  • Screenshots with text compress badly as JPEG. The sharp edges around letters live in the high frequencies JPEG throws away most aggressively, so text becomes noticeably fuzzy. Keep screenshots in PNG or WebP lossless.
  • The slider is a hint, not a guarantee. Setting quality to 50% does not mean you get half the file size - the actual reduction depends on how compressible the image content is. A photo of clear blue sky shrinks dramatically; one of a busy forest floor barely budges.
  • Color profiles are dropped. An ICC profile embedded in a camera JPEG does not survive the canvas re-encode. For color-critical work (print), preserve the profile with a tool like ImageMagick's -profile flag.

A Short History of Image Compression

JPEG was standardized in 1992 as ISO/IEC 10918-1 and remains the most widely deployed image codec in history. PNG (W3C Recommendation, 1996) took over where JPEG struggled: lossless, transparency-aware, and good for screenshots and icons. WebP (2010) was Google's first serious attempt at a single codec that could do both lossy and lossless plus transparency, and it now enjoys 98% browser support. AVIF (2019), based on the AV1 video codec as a still-image container, pushes even further: roughly 50% smaller than JPEG at equivalent quality, with 10-bit color and HDR metadata built in. It is supported everywhere except Edge and some older Safari versions. JPEG XL is the forward-looking option with lossless JPEG re-encoding and generation-loss-free edits, but browser support has stalled. For now, JPEG and WebP cover the practical needs of 99% of web workflows.

How This Stacks Up

Squoosh.app is the closest competitor and deserves its reputation: it exposes codec-specific knobs (Mozjpeg's trellis quantization, AVIF's tile settings), ships a side-by-side comparison slider, and includes advanced preprocessors. This tool is faster for the "just shrink it" workflow - one slider, one button, one download. For server-side batch compression, nothing on the web beats a Node pipeline using sharp (libvips), or ImageMagick's magick mogrify -quality 75 *.jpg for a folder. Specialized services like TinyPNG run more sophisticated perceptual encoders than any browser exposes, which is why they consistently beat a raw Canvas export on PNG files. Use this tool when privacy matters and you need a fast result; use Squoosh when you want to inspect codec differences; use a CLI or service when you are compressing hundreds of files at once.

Frequently Asked Questions

Does the image leave my browser during compression?

No. The uploaded file is decoded locally, drawn into an off-screen canvas, and re-encoded through the browser's native JPEG or WebP encoder via <code>canvas.toBlob</code>. The network tab stays silent throughout, and no analytics event carries a pixel of your image data. If you compare the original and the output you can even watch both sit in the DevTools Memory panel without any outgoing request.

Why does quality 75% on a photo only cut the file size in half, not by three-quarters?

The slider controls the JPEG or WebP quantization table, not the file size directly. How much actually shrinks depends on how compressible the image is - a clear sky with a smooth gradient compresses dramatically, while a detailed forest floor with lots of high-frequency texture barely changes. Quality 75% might give you a 40% smaller file on one photo and 80% smaller on another.

Is re-compressing an already-compressed JPEG safe?

It always adds loss, even at high quality settings, because the DCT and quantization pipeline runs again. For minor size trims the visual impact is usually invisible, but after three or four generations you will see the classic "JPEG rot" - blocky edges, color bleeding, and halos. Always compress from the original master file if you still have it.

Why is WebP typically smaller than JPEG at the same quality slider value?

WebP uses VP8-style intra-frame prediction, which predicts each block from the surrounding decoded context before encoding only the residual. That predictor pipeline catches smooth gradients and repeated textures more efficiently than JPEG's block-independent DCT. On typical photos, WebP is 25-35% smaller for the same perceived quality, and the advantage grows at low-quality settings where blockiness is more visible.

Can I compress transparent PNGs without losing transparency?

Yes, but only if you pick WebP as the output format. JPEG has no alpha channel and will flatten transparent pixels to white during export. WebP supports both lossy and lossless compression with alpha, so a logo with transparency can shrink from a 50 KB PNG to a 10 KB WebP and still drop onto any background cleanly.

Why does my compressed screenshot of text look blurry?

JPEG compression is tuned for photographs, which contain mostly smooth gradients. Screenshots of text have hard, high-contrast edges that live in exactly the frequency bands the JPEG quantizer throws away most aggressively. For screenshots, use PNG (lossless, well-compressed on low-color content) or WebP lossless mode - you will get a smaller file AND sharper text.

Will compression remove my EXIF and GPS data?

Yes. The Canvas 2D export pipeline starts from raw RGBA pixels that contain no metadata, so EXIF tags like camera model, ISO, exposure, and GPS coordinates are stripped. If you want to keep EXIF on a compressed output, a desktop tool like ExifTool can copy the tags from the original into the compressed file afterward.

Is there a file-size limit the browser enforces?

There is no hard cap on input file size, but very large images (20 MB+ or 30+ megapixel) can run into the browser's canvas memory limit around 268 million pixels (16,384 squared). Below that, the main constraint is time: decoding and re-encoding a 20 MB file takes a few seconds on a modern laptop and noticeably longer on a budget phone.

How does this compare to TinyPNG for PNG files?

TinyPNG uses a color quantization step that reduces the palette to 256 indexed colors, which often cuts PNG file size by 70% with barely noticeable quality loss. The browser-native PNG encoder in Canvas does not do that, so your compressed PNG here will be larger. For PNG-only workflows where file size is critical, TinyPNG or its CLI equivalent <code>pngquant</code> will beat this tool by a lot.

Should I pick JPEG or WebP for a public website in 2026?

WebP is now supported in 98%+ of active browsers (only very old Safari and IE are out), so it is a safe default for new sites. The industry best practice is actually to serve both via a <code>&lt;picture&gt;</code> element - WebP as the primary source and JPEG as the fallback - and let the browser pick. For social media uploads where the destination platform controls encoding, use JPEG as the upload so you do not double-encode later.

More Image Tools