Image Compression Tool

Online Image Compression: A Trade-off Between Quality and Size, Not "Smaller Is Always Better"

Image compression is not simply "making a file smaller" — it is a trade-off between acceptable quality loss and a smaller file size. This tool's quality slider (default 80%) is exactly that trade-off knob: lower it and the file shrinks but detail softens; raise it and quality holds but the file grows. Once you see it that way, you stop chasing the lowest possible quality and start picking a level that fits the job.

All compression runs locally in your browser through the Canvas API — files never leave your device, so it is private and gives instant feedback. It suits site owners, e-commerce sellers, creators, and anyone who wants to trim image weight and improve load performance.

Lossy vs Lossless: Two Very Different Ways to "Slim Down"

Compression algorithms split into two families with completely different mechanics, which decide how small you can go and whether information is discarded:

When you compress a PNG below quality 100, this tool smartly converts it to JPEG to win real savings — the cost is that transparency turns white. If you must keep transparency, keep PNG or switch to WebP (see the format table below).

Format Efficiency Compared (Same 4000×3000 Sample Photo, Measured in Browser)

We built a 4000×3000, 24-bit true-color sample (sky gradient, colored building blocks, and high-frequency detail to mimic a real photo) and measured each format's output with the exact same canvas.toBlob logic this tool uses. Raw pixel data is about 34.3 MB; as a camera-export baseline its high-quality JPEG (quality 95) is about 5.73 MB.

* AVIF encoding needs a server or dedicated tool; this tool (and most in-browser Canvas encoders) does not export it directly. The figure above is the typical saving from Google / AOMedia documentation, for format-choice reference only.

Note: Measured size varies a lot with image content — busier, noisier photos compress harder in JPEG and WebP; flat solid-color images compress even smaller. The table is a relative reference from a real sample, not a fixed multiplier.

Quality–Size Curve: Measured Output at Each Level (Tool Default = 80)

Using the same 5.73 MB baseline photo, we changed only the quality slider and watched this tool's real output (everything else unchanged):

Key finding: quality 100 is 71.7% larger than 95. Quality 100 triggers near-lossless re-encoding, discarding far less, so the file balloons. For web use, 80–85 is already the sweet spot; pushing past 95 usually just adds bytes.

Standard Differences: Local Web/Print Norms vs International Core Web Vitals

The same image has different "pass lines" per context. Below we put local and international norms side by side so you can benchmark:

Pixels, DPI, and Physical Size: Screen Display Does Not Need 300 DPI

Note: "DPI (dots per inch)" only matters for printing. Screens render by CSS pixels and ignore DPI — a 1920-pixel-wide image shows at 1920 pixels wide whether the display is 72 DPI or 300 DPI. Only printing needs enough pixels for the physical size.

The formula: required pixels = physical inches × DPI, and 1 inch = 2.54 cm. In other words, DPI does not create pixels out of nothing; if the source lacks pixels, raising DPI only prints bigger and blurrier.

Takeaway: for web images, set pixels to the display size first (e.g., phone width ~375–750 px), then compress to a good size here. Do not let "300 DPI" push you to export giant images the screen cannot use. To change dimensions first, use the Resize & Crop tool.

Three Real Examples (Tool Defaults, Numbers From the Measurements Above)

Example 1 (compress a camera photo): A 4000×3000 camera JPEG, baseline 5.73 MB. Compressed with this tool's default quality 80, output is 2574.5 KB — a 55.1% saving. Plenty for a web hero image.

Example 2 (PNG to JPEG rescue): The same shot saved as lossless PNG is 20546.8 KB. At default quality 80 the tool auto-converts to JPEG, output 2574.5 KB — an 87.5% saving. Note: if the source PNG had transparent areas, they turn white; to keep transparency, use Format Converter to switch to WebP instead.

Example 3 (reverse quality from a target size): You want the 5.73 MB original down to "about 2 MB, still decent". From the curve, quality 75 gives 2068.3 KB (63.9% saved) — the closest; if ~1.2 MB is acceptable, use quality 60. "Set the target size first, then read the curve to pick quality" beats blind dragging.

Frequently Asked Questions

Q: Why does compressing a PNG turn it into a JPG and drop the transparency?
A: PNG is lossless, so lossy compression at low quality barely helps. To get a real size win, the tool converts PNG to JPEG below quality 100 — and JPEG has no alpha, so transparent areas fill white. To keep transparency, stay PNG or move to WebP or AVIF.

Q: Why is quality 100 sometimes larger than quality 95?
A: Quality 100 triggers near-lossless re-encoding, discarding almost nothing, so the file is about 71.7% larger than at 95 (measured). Web use never needs 100.

Q: What quality should I use for web images?
A: Photos: 80–85 is the sweet spot (this tool defaults to 80, ~55% saved); thumbnails can go to 60; text and line art should use PNG or WebP to avoid jaggies.

Q: WebP or JPEG for the same image — which do I pick?
A: Prefer WebP on modern browsers — better detail at equal size, smaller at equal quality (measured: WebP q80 beats JPEG q85 on size). Keep a JPEG copy only for legacy systems. Convert with Format Converter.

Q: How much DPI do I need for screen? Is 300 DPI necessary?
A: Screens render by CSS pixels and ignore DPI; 300 DPI is for print only. Size web images by display pixels and skip the 300 DPI chase. See the table above.

For a full optimization walkthrough, read the blog post How to Compress Images Online: Complete Guide; to squeeze an image into text for transfer, see Text Compress / Decompress.