Image Compressor — JPG, PNG, and WebP

Modern browsers ship with built-in JPEG, WebP, and PNG encoders reachable through one Web API: HTMLCanvasElement.toBlob(callback, mimeType, quality). The compressor draws your image into an off-screen canvas, asks the browser to encode it at the chosen quality, and offers the resulting Blob as a download via an object URL. No part of the file leaves the page — you can watch your browser's Network tab while using the tool to confirm.

The encoded byte count depends on three things: pixel count, encoder family, and quality setting. Pixel count is a direct multiplier (twice the pixels, roughly twice the bytes). The encoder family sets a baseline — WebP averages 25–34% smaller than JPEG at equivalent perceptual quality, per Google's published WebP study. Quality moves you along a non-linear curve: between q=90 and q=100 the size doubles for almost no visible improvement; between q=40 and q=60 the size halves for noticeable quality gain.

The size estimator on the tool uses an empirical bits-per-pixel curve fitted to JPEG-corpus measurements and the WebP study numbers:

bpp_jpeg(q) = 0.05 + 1.4 × (q / 100)^2.5
bpp_webp(q) = bpp_jpeg(q) × 0.70
bytes       = (pixels × bpp) / 8  +  ~1 KB header overhead

The 0.05 term is the asymptotic floor: even at quality 0 a JPEG file needs that many bits per pixel for the quantised DCT coefficients and Huffman tables. The 2.5 exponent captures the steep growth in size between quality 60 and 90 — the region where most visible detail is preserved. The estimator is cross-checked against a second formula that linearly interpolates a five-point lookup table; the two land within ±5% on every quality between 1 and 100. The page above runs the estimator on the first queued image; the actual encoder may differ by ±10–20% depending on image content (textured photos encode larger than flat-colour graphics at the same quality).

For each image the tool does five deterministic things:

1. Validate. Confirms the file is JPG, PNG, or WebP and within the size cap of 50.0 MB. Rejected files leave a specific reason in the queue rather than failing silently.
2. Decode. Loads the image into an HTMLImageElement so the browser uses its native decoder. Natural width and height are read from naturalWidth / naturalHeight.
3. Resolve dimensions. When a resize preset is selected, the longest side is scaled down to fit, preserving aspect ratio to the nearest pixel. Images are never scaled up.
4. Re-draw. The image is painted onto a new canvas at the target size withimageSmoothingQuality = "high" (a bicubic-class resampler in current browsers). For JPEG output, the canvas is pre-filled with white so transparent source pixels don't turn black.
5. Encode & download. canvas.toBlob produces the compressed Blob with the requested MIME type and quality. The Blob is wrapped in an object URL and offered as a download with the matching file extension.

Each preset chip on the tool maps to a quality value on the 0–100 scale that canvas.toBlob accepts. The same q-value is read by every browser's JPEG and WebP encoder, so the same preset behaves consistently across Chrome, Edge, Firefox, and Safari.

• MDN — HTMLCanvasElement.toBlob (browser-native JPEG/WebP/PNG encoder)
• MDN — CanvasRenderingContext2D.drawImage (resampling and alpha handling)
• Google — WebP Compression Study (25–34% smaller than JPEG at equivalent quality)
• ITU-T T.81 — JPEG specification (DCT, quantisation, Huffman coding)
• web.dev — Use optimized images (image size vs perceptual quality guidance)

The size estimator and the cited compression-vs-quality relationships were last cross-checked against the above sources on 2026-05-11. The page is reviewed when browsers ship a new lossy encoder generation or when Google refreshes the WebP study.