Skip to main content

Image Compressor

What it does

The Image Compressor re-encodes an image at a chosen quality level and shows the resulting file size next to the original in real time. JPEG and WebP support a quality slider from 1–100; PNG is lossless by default and re-encoded as-is. The percentage savings appear next to the new size, so you can see “I saved 64% by dropping to quality 70” rather than guessing whether the trade-off is worthwhile.

Common situations

You’re auditing why a marketing page scores 50 on PageSpeed and finding that the hero photograph alone is 4MB. Compression at quality 75 typically halves photograph weight without visible loss. The audit becomes a two-minute fix rather than a re-shoot.

You’re preparing email creative for a campaign and the email tool caps total weight at 2MB. Inline images plus rendered HTML can blow that limit fast; compressing the embedded photographs to 100KB each keeps the campaign deliverable.

You’re publishing an image-heavy blog post (a tutorial with screenshots, a case study with multiple photographs) and you want page weight under 2MB total. Without compression, ten images at 500KB each is already 5MB. With compression at the right quality, the same set might be 1.5MB total with no visible loss.

You’re preparing assets for a build pipeline that does not have automated image compression. The pipeline serves raw uploads; the optimisation has to happen before commit. Pre-compressing locally produces the same result as the pipeline would do, but at upload time rather than build time.

You’re publishing photography that will be re-shared on social platforms. Most platforms aggressively re-compress everything they receive. Pre-compressing to a known quality value removes some unpredictability — the platform may still degrade further, but the starting point is controlled.

What you need to know

JPEG and WebP are lossy formats — they discard information during encoding to save space, with quality controlling how much. The encoder applies frequency-domain compression (the maths behind JPEG is the discrete cosine transform; WebP uses block-based prediction plus arithmetic coding) and the quality parameter controls how aggressively to round and discard high-frequency components. At very high quality (95+), the difference is invisible at typical viewing distances; at very low quality (below 50), JPEG produces visible blocking and ringing artefacts.

PNG is lossless — it uses dictionary compression (DEFLATE) and the only “quality” decision is which compression level to use, which trades CPU time for output size. PNG is rarely worth choosing for photographs (file size will be much larger than JPEG/WebP) but is the right choice anywhere transparency matters or where exact pixel preservation is required.

The browser exposes encoding through canvas.toBlob, which produces a real encoded file with the requested MIME type and quality — the same encoder you would get from a server-side ImageMagick call. Different browsers use slightly different encoder implementations (Chrome uses libwebp for WebP, Safari uses its own); output sizes can vary by 5–10% across browsers for the same source and quality value.

WebP is the modern default for new web work. It supports both lossy and lossless modes, plus a full alpha channel, and produces smaller files than JPEG or PNG at equivalent perceived quality. Browser support is universal in 2026 — every browser shipped after 2020 supports it. The compatibility argument for sticking with JPEG no longer applies for general web work.

AVIF is the newer-still format that produces even smaller files than WebP, particularly for photographs. Browser support is now solid (all modern browsers support it as of 2024) but encoder cost is higher — generating AVIF takes noticeably more CPU than WebP. For build-time encoding it is the right choice; for browser-based real-time encoding it is borderline.

The “right” quality value depends on the image type. Photographs compress to 70–85 with no visible loss. Screenshots with sharp edges and text need 85+ to avoid visible artefacts at the edges. Graphics with flat colour areas are usually better as PNG (lossless) regardless.

Frequently asked questions

What’s the best quality setting for JPEG?

70–85 for photographs. Below 70 starts looking soft; above 85 the file size grows fast for diminishing visual return. For graphics and screenshots, push to 90+ or use PNG.

What’s the difference between JPEG and WebP?

WebP is more efficient — it produces smaller files than JPEG at equivalent quality, often 25–35% smaller. It also supports transparency, which JPEG cannot. Browser support is now universal; there is no compatibility reason to default to JPEG over WebP in new web work.

Does compressing an image multiple times degrade it?

Yes — each lossy compression pass discards information that cannot be recovered. Compress once from the highest-quality source, never re-compress an already-compressed file.

Can I compress images in bulk?

Not in this browser tool. For bulk work, command-line tools (ImageMagick, sharp, cwebp) handle dozens of files in seconds. Use the browser tool for one-off cases or quick experiments.

Why does a “quality 80” JPEG sometimes look worse than a “quality 70” WebP?

WebP and JPEG use different encoding methods, so the quality numbers are not directly comparable. WebP’s quality 70 often looks visually equivalent to JPEG’s quality 85. Compare visual output, not numerical values.

Does compression strip metadata?

Re-encoding through canvas strips most embedded metadata (EXIF, geotags, copyright). Sometimes desirable (privacy), sometimes not (attribution). If you need metadata preserved, use ImageMagick with +strip flag or sharp in Node with withMetadata().

What about AVIF and other newer formats?

AVIF produces even smaller files than WebP, especially for photographs. Browser support is now widespread. The trade-off is encoder cost — generating AVIF is slow, particularly for high-quality output. Best used at build time, not browser-time.

Should I always compress PNGs?

PNG is already lossless-compressed, but the compression level varies. Tools like pngquant, oxipng, and optipng apply better compression algorithms than default encoders. For PNG, “compression” usually means stripping metadata and re-encoding with a stronger DEFLATE pass.

Common problems

Problem: Compressed image looks fine on my screen but artefacts visible on a colleague’s.

Quality settings interact with display calibration and viewing distance. What looks fine on a laptop at arm’s length may look harsh on a desktop monitor at closer distance. Test at multiple settings; err on the side of higher quality for content that will be viewed on large displays.

Problem: WebP at quality 80 produces a larger file than JPEG at quality 80.

WebP’s encoder occasionally produces larger output for very small images, very simple graphics, or when the source already has compression artefacts. Test both formats and pick the smaller for the specific image — not all images favour WebP equally.

Problem: PNG output is enormous despite “compression”.

PNG is lossless. For photographs, file size will always be far larger than JPEG or WebP. PNG is the wrong format choice for photographic content; switch to JPEG or WebP via the Image Format Converter.

Problem: Compression added visible “halos” around hard edges in a screenshot.

JPEG’s frequency-domain compression performs poorly on hard edges (text, UI lines, sharp transitions). Use PNG for screenshots, or use WebP at quality 90+. JPEG at any quality produces visible halos around edges.

Problem: Images compressed identically twice produce different-sized files.

Compression is mostly deterministic but encoder variations and rounding can produce tiny size differences. The differences are negligible (a few bytes at most) and not worth investigating unless reproducibility is critical for a content-hashing system.

Quick guides

For WordPress sites: The WP Beacon Plugin handles upload-time compression automatically. Configure quality (default 80 for JPEG, lossless WebP) and forget about per-image decisions.

For build pipelines: Use sharp via Node, integrated into your build step. sharp(input).jpeg({ quality: 80 }).toFile(output) is the typical pattern. Run during the build, cache the output, never re-compress on every page request.

For ad-hoc bulk work: Use ImageMagick. for f in *.jpg; do convert $f -quality 80 compressed/$f; done compresses every JPEG in a folder. Add +strip to remove metadata.

Tips

  • Quality 70–85 is the sweet spot for photographs. Below 70 starts looking soft; above 85 the file size grows fast for diminishing visual return.
  • For graphics with sharp edges (screenshots, diagrams, logos) prefer PNG or WebP — JPEG produces visible halos at edges where pixel values change abruptly.
  • WebP is supported by every modern browser. There is no good reason to default to JPEG over WebP for new web work in 2026 unless you have a specific compatibility constraint.
  • Compress after resizing. A high-resolution source compressed first, then resized, accumulates compression artefacts the second pass cannot remove.
  • For build-time pipelines, AVIF outperforms WebP for photographs at the cost of encode time. For browser-time work, WebP remains the practical choice.
  • If a compressed image looks worse than expected, check whether it has been recompressed through your CMS or CDN. Multiple compression passes compound losses.

Related tools in this suite

The natural pairing is the Image Resizer — resize first, compress second. The Image Format Converter is the right tool when the question is purely “this should be a different format” rather than “this should be smaller”.

What this looks like at scale

A site with hundreds of images, content editors uploading new ones daily, and no automated pipeline will accumulate weight that nobody sees coming. The WP Beacon Plugin addresses that on WordPress — every image uploaded gets compressed and re-encoded automatically based on rules you configure once. The systems we build handle the equivalent for non-WordPress platforms, including the build-time pipeline integrations that turn image optimisation from a manual ritual into a property of the deployment.

Take it further

If image weight is a recurring page-performance issue, manual compression is treating the symptom. The cure is automation: every uploaded image goes through compression rules without human intervention. Talk to us about the build-pipeline work that takes image optimisation off your team’s checklist permanently.