Online Image Compressor: Shrink JPEG, PNG, and WebP

What Is Image Compression

Image compression reduces file size in two broad ways:

• Lossless: Pixels can be restored exactly (PNG); size wins are limited
• Lossy: Trades some detail for much smaller files (JPEG, lossy WebP)

ToolVault's Image Compressor re-encodes locally via Canvas — adjustable quality and max width, JPEG/PNG/WebP conversion, originals never uploaded. The pipeline is decode → optional downscale → encode, so the download is a new file, not an in-place lossless rewrite of the container.

Why You Need Image Compression

1. Web performance: Images dominate page weight; smaller bytes cut LCP-related waits
2. Bandwidth cost: CDN and egress bills track bytes
3. Upload caps: Forms and portals often enforce 100KB–2MB limits
4. Mobile networks: A right-sized asset beats shipping a 4000px original for CSS to shrink
5. Base64 inflation: Compress before Image to Base64 to offset the ~33% encoding tax

Image Format Comparison

Format selection

• Photos: Prefer WebP (often 25–35% smaller than JPEG at similar look); keep JPEG when maximum compatibility matters
• Screenshots/icons: PNG or WebP when you need alpha; opaque screenshots often shrink a lot as JPEG/WebP
• Logos: SVG when possible; rasterize only when the pipeline requires it
• This tool's outputs: JPEG / PNG / WebP (native Canvas). AVIF encode is out of scope here.

How to use the compressor

Open the Image Compressor:

1. Drop or pick an image the browser can decode (JPEG / PNG / WebP, etc.)
2. Use a quality preset (Web 70% / Balanced 80% / High 90%) or the slider. PNG disables the slider — PNG export is lossless re-encode
3. Use a width preset (Original / 1920 / 1280 / 800) or type a max width (0 = no resize). Downscale before cutting quality when you have a hard size budget
4. Pick the output format. Transparent PNG → JPEG fills alpha with white (JPEG has no alpha)
5. Compress, then compare original size / compressed size / percent saved / bytes saved plus dimensions before downloading

Side-by-side previews help spot ringing on text edges and banding in gradients.

Quality vs file size

Rule of thumb: Start at Balanced 80% for photos. Under a hard cap, drop max width to ~2× display size first, then nudge quality down. Never recompress an already-compressed export as your source — always re-export from the original.

The format decision tree (2026)

Photographic content: WebP at quality 75–85 (commonly 25–35% smaller than JPEG at equal visual quality) — AVIF when every byte matters and your encode/decode chain supports it. Graphics/screenshots/flat colors: PNG (lossless, sharp text) or lossless WebP. Few-color icons: SVG when the pipeline allows. Animated: dedicated WebP/AVIF frame tools beat GIF; Canvas compressors usually flatten to a single frame. The compressor applies the policy you set per file; the tree above is that policy.

Lossy quality: where artifacts show up

JPEG fails first on sharp color transitions (UI text, red-on-white) as ringing and blockiness — screenshots with text degrade early because text is exactly what DCT codecs handle poorly. WebP tends to blur before it rings, but aggressive settings still ruin UI copy. Working thresholds: photos often tolerate 60–75; UI screenshots want 85+; 95+ is usually placebo on camera JPEGs that already carry sensor noise. Quality is non-linear — 80→70 often saves more than 90→80. Pair with right-sizing.

Resize before compress

Serving a 4000px camera original into a 400px slot wastes nearly all bytes regardless of quality. Order matters: downscale first (2× display for retina, no more), then compress — artifacts amplify if you compress at full resolution and scale in CSS. Srcset still needs the sizes generated; a tool that only recompresses at original dimensions does half the job. Stack: right size → right format → right quality → cache headers. This compressor handles the middle two locally with optional max-width.

Canvas pipeline boundaries (implementation notes)

Documented on the tool as well — these are browser re-encode limits, not silent gaps:

1. EXIF / GPS / ICC are stripped: drawImage + toBlob keep pixels only. Useful privacy side effect; keep a master if you need lens data or embedded profiles.
2. Not a lossless JPEG rewrite: Even JPEG→JPEG is a fresh quantization; high quality still changes bytes.
3. PNG “compress” may not shrink: Quality is ignored for PNG; an already-optimized PNG can stay flat or grow — switch opaque images to JPEG/WebP.
4. Animation drops: GIF/animated WebP via Canvas typically keeps one frame.
5. Decode failures: Some HEIC/niche codecs need OS support; if load fails, confirm the browser can preview the file at all.

FAQ

Does compression always reduce quality?

Lossy formats at ~80 are usually imperceptible for photos. Lossless PNG re-encode keeps pixel precision but may not shrink. Trust the preview and the size stats.

Are online compressors safe?

This tool runs entirely in the browser — images are not uploaded. Metadata stripping (above) is part of the Canvas path.

How much smaller is WebP vs JPEG?

Often about 25–35% at similar visual quality. If canvas.toBlob('image/webp') works in the target browser, export WebP directly and keep JPEG as a fallback for older clients.

Why did my file get larger?

Common cases: optimized JPEG → PNG; quality too high with no resize; source already heavily compressed. Switch format and/or reduce max width, then compare again.

Triage notes

The rule of thumb fixes the order: downscale first, then lower quality — usually more effective than quality alone; under a hard size cap, drop max width to 2× the display size (retina) before touching quality. The "Canvas path boundaries" section sets its tone in the first sentence: these are not hidden defects but inherent limits of browser re-encoding — stripping EXIF/GPS/ICC is a privacy win for sharing, while anyone depending on lens data or color profiles should back up the original first. Both counterintuitive conclusions come with reasons: PNG "compression" often doesn't shrink (lossless re-encoding; opaque images belong in JPEG/WebP), and re-compressing an already-compressed export stacks artifacts, so always re-export from the original.

Provided by ToolVault. Related tools: Image Compressor, Image to Base64, Base64 to Image. More tools on the homepage.