Compress image

Lighter JPG, PNG and WebP with real gains shown. Free, no upload. 1 GB max · Up to 1 GB · Processed locally, never sent to a server.

A photo from a recent phone weighs between three and eight megabytes. Multiply that by the fifteen visuals on a single page and a decent site turns into a slow one, while the same file bounces off the attachment limit of a work email. Bringing that weight down without the difference showing is a question of encoding, not of dimensions: this tool does not touch the resolution of the image, it rewrites the file with a codec more efficient than the original one.

Three engines ship with the page, compiled to WebAssembly and served from the site’s own assets folder: MozJPEG for JPEG, libwebp for WebP, OxiPNG for PNG. These are the codecs of the jSquash project, the ones Squoosh uses. You set the quality, from 30 to 95 %, and the output format: keep the format of the file, force JPG, or force WebP.

Every result carries a detailed note: size before, size after, percentage saved and the name of the engine used, for example "MozJPEG q75". When compression gains nothing, the tool hands back the original file untouched rather than a heavier version. Several images can be dropped at once, and they are processed one after another without leaving the page.

How to use it

  1. Drop your images The picker takes JPG, PNG and WebP, several at a time. The list shows the size of each file and lets you drop any of them with the ✕ button before you start.
  2. Set the quality slider From 30 to 95 % in steps of 5, sitting at 75 by default. It concerns JPG and WebP only: the PNG branch ignores it, since nothing is degraded there.
  3. Choose the output format Keeping the format follows the extension of each file; JPG and WebP force a conversion on the whole batch, including the PNG files you dropped.
  4. Click Run Files are encoded one after another. The first run fetches the codec it needs, which then stays in cache for the images that follow.
  5. Read the note under each result It gives the saving and the engine used, or states that the image was already optimised and the original kept. The ↓ Download all (ZIP) button gathers the whole batch into a single archive.

One codec per format, and which one runs when

When the format is kept, the format of each file is read from its MIME type and its extension, then routed to the matching engine: a .jpg goes to MozJPEG, a .webp to libwebp, a .png to OxiPNG. Forcing JPG or WebP imposes the same engine on the whole batch, whatever the input format was.

The three codecs are hosted on the site itself, not pulled from a third-party service. If they cannot be reached, the tool falls back on the encoder built into the browser and writes that in the note as "browser": the result is still usable, only less compact.

Lossy and lossless are two different operations

MozJPEG and libwebp compress with loss: they break the image down, then discard information where the eye is least likely to notice it, according to the quality level asked for. The original pixel cannot be restored, and recompressing an already compressed file stacks the damage.

OxiPNG does not modify the image on screen: it tries several prediction filters and recomputes the compressed stream to find the most compact representation of the same pixels. This is a lossless rewrite, run here at level 3, with alpha channel optimisation.

That difference explains a point that often puzzles people. A PNG that has already been through an optimiser will gain almost nothing: there is no visual quality left to spend, only an arrangement of bytes to improve, and it is already improved. On a photographic PNG, the real saving comes from changing format.

Choosing the quality and the output format

For images headed to the web, 75 % is the usual balance point: at normal reading distance the gap with the original does not show. Go up to 85 or 90 % if the image will be printed or edited afterwards, because every later step will start from this file. Below 50 %, blocking becomes visible in soft gradients and in dark areas.

WebP generally produces a smaller file than JPG at equivalent quality, and it handles transparency, which JPG does not. Forcing JPG on a transparent PNG therefore flattens it: that is the only case where this selector changes the appearance of the image other than through compression.

The safety net, and what the output file no longer contains

After encoding, the size obtained is compared with the size of the file you dropped. If it is greater than or equal, the original is returned as it stands, with a note saying the image was already optimised and the original kept: you never leave with a heavier file than the one you brought.

For JPG and WebP, the image is decoded into raw pixels before being re-encoded: the EXIF metadata, capture date, camera model and GPS position, is not written back into the file produced. That is a loss if you are archiving, an advantage if you are publishing. The PNG branch works directly on the bytes of the file.

Frequently asked questions

Does the quality slider change anything on a PNG?

No. When the format is kept, a PNG goes through OxiPNG, which works without loss, so the slider is ignored. To act on it, convert the file to JPG or to WebP.

What does "browser" at the end of the note mean?

That the WebAssembly codecs could not be loaded and that the encoder built into the browser took over. Reloading the page from the live site restores MozJPEG, OxiPNG and libwebp.

Does compressing twice in a row improve the result?

No, and it damages the image: each pass through JPG or WebP removes information for good. If the first setting does not suit, start again from the original file with a different quality.

Do my GPS coordinates stay in the compressed photo?

Not in a JPG or WebP output: encoding starts from the pixels and writes no EXIF block. If that information is useful to you, keep the original file on your side.

A 60 megapixel image is refused.

The codec sets a limit of around fifty megapixels so as not to saturate memory. Reduce the resolution first with Resize an image.

Does the file name change?

Yes, the suffix -compresse is added before the extension, and that extension follows the format actually produced. Your original file is neither modified nor replaced.

Similar tools

Discover other tools

Categories