Image Compressor

What is image compression?

Image compression is the process of re-encoding an image file so it takes fewer bytes while keeping the visible content close enough to the source to be useful. The two main kinds are lossless compression, which preserves every pixel exactly and is what the PNG format always uses, and lossy compression, which discards some pixel detail in exchange for a much smaller file and is what JPEG and lossy WebP use. Most production web imagery is a balance between the two.

This compressor works in the same format as the source — a JPG stays a JPG, a PNG stays a PNG, a WebP stays a WebP — and re-encodes the file with a balanced quality default per format. It never resizes, crops or upscales, and it never silently changes the file format.

Why compress an image?

• Faster page loads. Smaller image payloads reduce download time and decoding work on the user's device, which directly improves the page experience.
• Email and form upload limits. Many email services and CMS forms reject files above a few MB. Compressing first lets the same image go through.
• Re-using an old asset at a new, smaller budget. A PNG or JPG from a previous project can be brought back to a tighter file size band without re-designing the image.
• Keeping the same format in your repo or CMS. When the destination already speaks the source's format, re-encoding in place is more useful than swapping to WebP.

Compression does not guarantee a smaller file for every source. A tightly optimised source may end up similar in size or fractionally larger after a re-encode. The result panel on this page shows the measured sizes so the comparison is honest.

Quick Answer

The Image Compressor reduces the file size of a single PNG, JPG or WebP image in the same format as the source and at the same pixel dimensions. PNG is re-encoded with Pillow's optimize pass on; JPEG is re-encoded at quality 80 with optimization on and alpha flattened on white; WebP is re-encoded at quality 80 when the source has no transparency and losslessly when it does. The output keeps the source extension and is a drop-in replacement for the original.

Requirements

Supported input

PNG, JPG, JPEG or WebP, up to 10 MB. SVG and GIF are not accepted: SVG is a vector format and GIF needs animation-aware processing the MVP does not include.

Output format

A single file in the same format as the source, named after it. PNG keeps its PNG extension, JPG keeps JPG, WebP keeps WebP. The format never changes silently.

Dimensions

Preserved exactly. A 1200 × 800 source becomes a 1200 × 800 output. No resize, no crop, no upscale.

How it works

1. 1 Upload. Choose a PNG, JPG or WebP file up to 10 MB.
2. 2 Compress. The compressor re-encodes the file in its original format: PNG with optimize on, JPG at quality 80 with optimize on, WebP at quality 80 (or lossless when the source has transparency).
3. 3 Compare and download. The result panel shows the measured original size, the compressed size, the bytes saved and the percentage change. Download the smaller file in the same format.

Compressing for the web

Image compression only matters in the context of a real page delivery budget. Chrome for Developers publishes the Lighthouse audits PageSpeed Insights actually run, and the two audits that touch images are stated independently:

• Efficiently encode images asks whether the file could have been smaller at the same rendered dimensions by using a more efficient format or encoder. Per the Chrome for Developers audit docs, the threshold is approximately 4 KiB of potential savings per image.
• Properly size images asks whether the rendered display size on the page is meaningfully smaller than the source's intrinsic pixel dimensions. The Lighthouse audit flags an image when the displayed pixel size is far smaller than the file's actual pixel size, regardless of compression level.

Compressing an image that is too large on the page does not solve the Properly size images flag — the page would have to ship a smaller render box or a smaller source. Compressing an image that is already close to its render box does not earn Efficiently encode images credit if the file is already tightly encoded. The two audits are independent and the page must address both to clear the image-delivery section of a Lighthouse run.

Common compression mistakes

These are the issues that come up most often when compressing an image. Each one is rooted in a property of the format or the encoder rather than in this specific tool.

• Expecting a fixed percentage reduction. The output size depends on the source content, the source's existing compression level and the chosen quality. A tightly optimised source may shrink very little; a flat-colour graphic shrinks a lot. Compare the measured sizes on the result panel before deciding whether to keep the output.
• Confusing compression with resizing. Compression keeps the same pixel dimensions and reduces the file size. Resizing changes the pixel dimensions (and usually the file size as a side effect). If you need a smaller canvas, use a resizer first; if you need a smaller file at the same canvas, use this compressor.
• Compressing an already heavily compressed file. A JPG saved at quality 80 then re-encoded at quality 80 may end up roughly the same size or fractionally larger; the same is true for a tightly optimised WebP. Use the original in that case. This tool is most useful when the source was saved with conservative settings or has been edited since it was last encoded.
• Animating a flat PNG or WebP and losing the frames. This compressor runs on the first frame Pillow decodes, so an animated PNG or animated WebP source is flattened to a single frame in the output. If you need an animation-aware compressor, take the source into a tool that handles the frame schedule.

Check the output

After the compressor runs, verify these four things on the actual file before you upload it anywhere. The compressor shows the byte counts on the result panel; the rest of this list is a quick visual check that the smaller file is still the right file.

• Dimensions. Confirm the source's pixel dimensions still match the destination display slot. Compression does not change dimensions — the output is the same width and height as the input — but the check matters because compression alone does not fix an image that is far larger than what the page renders. Chrome for Developers' Properly size images Lighthouse audit is the first-party reference for that case; if the source has more pixels than the layout uses, resize before compressing, do not rely on compression to make up for it.
• File size. Confirm the compressed bytes are at or below the destination's documented limit (a CMS upload cap, an email attachment cap, a page payload budget) and below the size you actually need. The result panel shows the measured original and compressed sizes for the file you uploaded, so the comparison is honest. Chrome for Developers' Efficiently encode images Lighthouse audit flags images that could save roughly 4 KiB or more by a more efficient encoder or format — that is the page-level signal, not a per-file target.
• Visual quality. Open the output at the actual display size and look for JPEG block artefacts on text and sharp edges, colour banding in sky or gradient regions, broken or white-haloed transparency, and smearing of fine detail (hair, fabric texture, small UI elements). Pillow's quality 80 on the 0 to 100 scale is the balanced default this compressor uses; if the visual check fails, the right move is to switch format (lossless PNG or lossless WebP for transparency, JPEG or WebP for a photograph) or to lower the compression level rather than to keep a broken file. A dedicated walkthrough of these four symptoms and their fixes lives on the over-compressed image guide.
• Real destination. Upload the final file to the actual page, CMS, email or design tool where it will be used, and view it there. Browser preview, design-tool preview and the live page can render colour, transparency and layout differently; the live destination is the only check that catches all of them at once. This is the same check the Optimize Images for the Web guide recommends, and it is the last step before the file is shipped.

Image Compressor vs WebP Converter

The two workflows answer different questions and they pair well rather than overlap. The Image Compressor reduces the file size of a PNG, JPG or WebP image while keeping the source format and the source dimensions. The WebP Converter changes the file format to WebP and may also produce a smaller file as a side effect, depending on the source and the WebP encoder settings. Use the compressor when you need a smaller file in the same format as the source. Use the WebP Converter when you want to ship WebP and the destination reads WebP. Combining both — first compress in the source format, then convert to WebP — is also a reasonable pipeline if the source is large.

WebP does not always produce a smaller file than an equivalent PNG or JPG, especially for small flat-colour graphics where the per-frame metadata is a noticeable share of the total bytes. The two tools report measured sizes, not promised reductions; the right tool for a given file depends on what the destination reads and how the source compresses, not on which tool claims a larger reduction.

Image Compressor vs Compress to KB

The two workflows answer different questions and they pair well rather than overlap. The Image Compressor uses one balanced default per format and never changes format or dimensions — a PNG stays a PNG, a JPG stays a JPG, a WebP stays a WebP, and the pixel count is preserved exactly. The Compress to KB sweeps quality toward a user-set KB budget and may change format (PNG → WebP, PNG → JPEG) or scale dimensions when the budget cannot be met at the source settings. Use this Image Compressor when the destination already accepts the source format and there is no byte budget. Use the Compress to KB tool when a destination asks for "under X KB" or "max Y KB" — the result panel on that tool reports whether the budget was met and whether the tool changed format or scaled.

Both tools report measured sizes on the result panel, not promised reductions. The Compress to KB tool is honest about the cases where the target cannot be hit — the panel shows the best-effort file and a "Could not reach X KB" note rather than padding the result. Pair the two tools when one is not enough: first use the Image Compressor for a balanced same-format re-encode, then run Compress to KB only if the destination also enforces a specific byte budget.

What the compressor actually changes

The compressor is a single re-encode in the source's own format. Each format has a different encoder with different trade-offs — the behaviour below is the real per-format path the workflow runs, not marketing shorthand.

The compressor never resizes, crops or upscales. It also never silently changes the file format: the downloaded file keeps the source's extension, and the file bytes match that extension. A misnamed upload (for example a PNG saved as photo.jpg) is detected by Pillow's decoder and written out with the correct extension so the file content and the file name agree.

Reading the result panel

The result panel shows three measured values: the original file size (read from the upload), the compressed file size (read from the downloaded file) and the bytes saved. There is no promised reduction and no estimated number — the panel is the same measurement you would make with any file-size tool, on the same source bytes.

Three outcomes are possible, and all three are shown honestly:

• Smaller. The most common case. The output bytes are fewer than the source and the panel shows the absolute saved bytes plus the percentage. The output is a drop-in replacement for the original at the same dimensions and the same format.
• No change. A re-encode at the same effective quality as the source can come out the same size to the byte. The panel shows Same size as original rather than disguising it as a small positive reduction. Keep the source if the file is already at the format and quality you want.
• Larger than original. Rare but real. A small flat-colour PNG carries per-frame metadata that can make a re-encoded file a few hundred bytes bigger than the source. The panel shows Larger than original — keep the source. Do not replace the original with the output in this case.

The bytes-saved number is the source's own measurement, not an average for the format. Treat it as one data point: it tells you what happened on this specific file, not what will happen on the next file you compress.

Sources

Each factual claim on this page — encoder parameters, format behaviour, browser compatibility and the WebP lossless option — is sourced from the canonical documentation below.

• Pillow (PIL) documentation - Image.save JPEG: https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#jpeg — Pillow JPEG encoder parameters, quality scale, optimize pass, progressive mode.
• Pillow (PIL) documentation - Image.save PNG: https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#png — Pillow PNG encoder behaviour, optimize flag, alpha preservation.
• Pillow (PIL) documentation - Image.save WebP: https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#webp — Pillow WebP encoder parameters, quality scale, lossless mode, method knob, alpha handling.
• MDN - Image file type and format guide: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types — Browser compatibility and format reference for JPEG, PNG and WebP, including transparency behaviour.
• WHATWG HTML Living Standard - Images: https://html.spec.whatwg.org/multipage/images.html — Authoring guidance for image elements and how browsers decode JPEG, PNG and WebP payloads.
• Chrome for Developers - Efficiently encode images (Lighthouse): https://developer.chrome.com/docs/lighthouse/performance/uses-optimized-images — First-party Lighthouse audit reference for image encoding efficiency, the threshold PageSpeed Insights uses to flag an image as worth re-encoding, and the metric definitions behind the 'saves bytes' score.
• Chrome for Developers - Properly size images (Lighthouse): https://developer.chrome.com/docs/lighthouse/performance/uses-responsive-images — First-party Lighthouse audit reference for image dimension efficiency: when an image's intrinsic pixel dimensions exceed what the page actually renders, and why that affects the performance audit independently of the file-format question. Resize the rendered canvas before compression is the operational implication.