HomeImage UtilitiesImage Compressor

big files. tiny output.

compress images up to 90% smaller without losing quality. 100% client-side — your images never leave your browser.

drop images here

or click to browse — up to 10 images

choose files

PNG, JPG, WebP

your images never leave your browser

What “compress” actually means here

Image compression is a slightly misleading name for what most tools — including this one — do. The image is not being compressed in place; it is being re-encodedinto a different file with different settings. The result happens to be smaller, usually much smaller, but the underlying operation is “decode the original, re-encode it with a tighter codec configuration, and save the new file.”

That distinction matters because it tells you what kinds of savings to expect from different formats and settings.

The three formats and what each is good at

JPEG

Lossy. Designed in 1992 for photographs. Throws away high-frequency detail that the human eye does not notice much — the kind of detail that exists in a tree leaf or a face but not in a screenshot of a slide deck. Performance on photos is excellent. Performance on UI screenshots, line art, or text is poor; you get visible artifacts around sharp edges (the “ringing” you see around dark text on a light background after JPEG compression).

PNG

Lossless. Designed for graphics with sharp edges and limited color palettes — UI elements, screenshots, logos, anything with text. The compression algorithm (DEFLATE, the same one in zip files) finds repeating patterns and stores them once. On a flat-color logo, this is dramatic — a 50KB raster can compress to 2KB. On a photograph, it is ineffective; PNG of a photo is often larger than the original JPEG.

WebP

Modern format from Google, supported in every current browser. Has both a lossy mode (typically 25-35% smaller than equivalent JPEG) and a lossless mode (typically 25-30% smaller than equivalent PNG). For most use cases shipping in 2026, WebP is the right output format. The two reasons you might still pick JPEG or PNG: an older recipient app that does not support WebP, or a workflow that explicitly requires the original format.

Lossy vs lossless: pick by content, not preference

The single most useful guideline for image compression is:

  • Photographs and complex images with smooth gradations of color → lossy (JPEG or WebP-lossy). The quality loss is invisible at 80-90% quality and the size savings are 5-10x.
  • Screenshots, UI, logos, line art, anything with text → lossless (PNG or WebP-lossless). Lossy codecs visibly destroy sharp edges; the size savings are smaller anyway because there is less high-frequency information to throw away.

The second-most-useful guideline: if you are not sure what the image is, try both and compare. The results are often surprising. A “photograph” that turns out to be mostly flat sky and a logo overlay might compress better as PNG. A “screenshot” that includes a photo within the UI might compress better as JPEG.

The quality slider

For lossy formats, the quality setting controls how aggressively the encoder discards information. Lower values mean smaller files and visible artifacts. Higher values mean bigger files and fewer artifacts.

Useful reference points for JPEG and WebP-lossy:

  • 95-100 — visually indistinguishable from the source. Useful when you need to compress without anyone noticing.
  • 80-90— the “sweet spot” for web delivery. Significant size reduction, no visible artifacts on most images.
  • 60-80 — visible artifacts on close inspection, especially around faces and skin tones. Still fine for thumbnails and previews.
  • Below 60 — visible artifacts to the casual viewer. Useful for placeholders or extreme bandwidth constraints.

The default in this tool is in the 80-90 range, which is where most experienced practitioners land for general web use.

Do not re-compress

Lossy compression is not idempotent. Each round of JPEG encoding throws away more detail. If you take a JPEG, save it, open it, and save it again at the same quality, the second save loses information that the first save kept. For a workflow that involves multiple edits, work in a lossless format (PNG or original RAW) and only encode to JPEG at the very end.

Why this runs in the browser

Re-encoding an image is a job perfectly suited to local processing. Browsers ship native canvas APIs that decode the source image, then re-encode it through the codec built into the browser's media stack. No server needed. The image you drop in does not leave the tab — relevant if it is a screenshot of an internal dashboard, a personal photo, or a document scan.

For sister tools that solve adjacent problems: see image format conversion, resizing, and HEIC to JPG conversion for the common iPhone-camera case where the source format is not supported on a destination platform.

What “compress” actually means here

Image compression is a slightly misleading name for what most tools — including this one — do. The image is not being compressed in place; it is being re-encodedinto a different file with different settings. The result happens to be smaller, usually much smaller, but the underlying operation is “decode the original, re-encode it with a tighter codec configuration, and save the new file.”

That distinction matters because it tells you what kinds of savings to expect from different formats and settings.

The three formats and what each is good at

JPEG

Lossy. Designed in 1992 for photographs. Throws away high-frequency detail that the human eye does not notice much — the kind of detail that exists in a tree leaf or a face but not in a screenshot of a slide deck. Performance on photos is excellent. Performance on UI screenshots, line art, or text is poor; you get visible artifacts around sharp edges (the “ringing” you see around dark text on a light background after JPEG compression).

PNG

Lossless. Designed for graphics with sharp edges and limited color palettes — UI elements, screenshots, logos, anything with text. The compression algorithm (DEFLATE, the same one in zip files) finds repeating patterns and stores them once. On a flat-color logo, this is dramatic — a 50KB raster can compress to 2KB. On a photograph, it is ineffective; PNG of a photo is often larger than the original JPEG.

WebP

Modern format from Google, supported in every current browser. Has both a lossy mode (typically 25-35% smaller than equivalent JPEG) and a lossless mode (typically 25-30% smaller than equivalent PNG). For most use cases shipping in 2026, WebP is the right output format. The two reasons you might still pick JPEG or PNG: an older recipient app that does not support WebP, or a workflow that explicitly requires the original format.

Lossy vs lossless: pick by content, not preference

The single most useful guideline for image compression is:

  • Photographs and complex images with smooth gradations of color → lossy (JPEG or WebP-lossy). The quality loss is invisible at 80-90% quality and the size savings are 5-10x.
  • Screenshots, UI, logos, line art, anything with text → lossless (PNG or WebP-lossless). Lossy codecs visibly destroy sharp edges; the size savings are smaller anyway because there is less high-frequency information to throw away.

The second-most-useful guideline: if you are not sure what the image is, try both and compare. The results are often surprising. A “photograph” that turns out to be mostly flat sky and a logo overlay might compress better as PNG. A “screenshot” that includes a photo within the UI might compress better as JPEG.

The quality slider

For lossy formats, the quality setting controls how aggressively the encoder discards information. Lower values mean smaller files and visible artifacts. Higher values mean bigger files and fewer artifacts.

Useful reference points for JPEG and WebP-lossy:

  • 95-100 — visually indistinguishable from the source. Useful when you need to compress without anyone noticing.
  • 80-90— the “sweet spot” for web delivery. Significant size reduction, no visible artifacts on most images.
  • 60-80 — visible artifacts on close inspection, especially around faces and skin tones. Still fine for thumbnails and previews.
  • Below 60 — visible artifacts to the casual viewer. Useful for placeholders or extreme bandwidth constraints.

The default in this tool is in the 80-90 range, which is where most experienced practitioners land for general web use.

Do not re-compress

Lossy compression is not idempotent. Each round of JPEG encoding throws away more detail. If you take a JPEG, save it, open it, and save it again at the same quality, the second save loses information that the first save kept. For a workflow that involves multiple edits, work in a lossless format (PNG or original RAW) and only encode to JPEG at the very end.

Why this runs in the browser

Re-encoding an image is a job perfectly suited to local processing. Browsers ship native canvas APIs that decode the source image, then re-encode it through the codec built into the browser's media stack. No server needed. The image you drop in does not leave the tab — relevant if it is a screenshot of an internal dashboard, a personal photo, or a document scan.

For sister tools that solve adjacent problems: see image format conversion, resizing, and HEIC to JPG conversion for the common iPhone-camera case where the source format is not supported on a destination platform.

more free tools

PDF utilities, image tools, developer helpers — all free, no signup.

Something wrong?