Elofyn / Tools / Image Compressor / About

About the Image Compressor

A short tour of what this tool does, what WebP is, how it manages to be smaller than JPEG and PNG at the same visual quality, and how to pick a sensible quality setting for the job in front of you. Back to the tool ↗

What this tool does

Drag a PNG or JPG into your browser. The image is decoded into an ImageBitmap, drawn onto an offscreen <canvas>, and re-encoded as WebP through the browser’s built-in encoder. A live quality slider lets you find the smallest file that still looks the way you want; the before/after byte readout shows exactly what you saved. When you’re happy, the Download button writes a <original-base>.webp file to disk. Nothing is uploaded. Nothing is logged. The image and every byte derived from it stay in the browser tab for the life of the session and are dropped when you reload or clear.

What WebP is and why it exists

WebP is an image format Google announced in 2010, derived from the VP8 video codec the company had acquired from On2 Technologies earlier that year. The goal was a single format that could replace both JPEG (for lossy photographs) and PNG (for lossless graphics with an alpha channel) with smaller files at comparable visual quality. Lossy WebP is essentially a still-frame of VP8’s intra-frame coding; lossless WebP is a separate codec with its own entropy model and a richer set of transforms tuned for non-photographic content. The format supports an alpha channel, animation, and ICC profiles, and is now standardised in IETF RFC 9649 (October 2024) — see citation [2] for the formal specification.

Adoption was slow at first because Safari held out for years. Safari 14 (September 2020) added WebP decode support, removing the “we can’t ship WebP because Safari can’t read it” objection for static delivery. Safari 16 (September 2022) finally added WebP encoding through HTMLCanvasElement.toBlob(‘image/webp’, q), which is the API this tool uses, and at that point the last major-browser holdout was gone. By 2026 effectively every browser users hit this tool from has both halves of the format. See citation [1] for the original Google announcement and project page.

The technical principles

Predictive intra-frame coding (lossy mode). Lossy WebP splits the image into 4×4, 8×8, and 16×16 macroblocks and, for each block, predicts the pixel values from the already-encoded neighbours (the row above and the column to the left). The encoder transmits only the residual — the per-pixel error between the prediction and the truth — and quantises it. This is structurally the same trick JPEG uses with its 8×8 discrete-cosine transform, but the extra intra-prediction step gives WebP roughly 25–35% smaller files than baseline JPEG at the same visual quality on typical web content. RFC 9649 specifies the block sizes, the prediction modes, the transform, and the entropy coder in detail.

Quality scale. libwebp and the cwebp command-line tool expose a 0–100 quality knob, and this tool maps its slider directly to that scale. The number is not a measured PSNR or SSIM — it is a knob that controls the quantiser step size. Real-world rules of thumb that come out of this: 80 is roughly visually-lossless for photographs on a phone screen; 60 is “still good for a blog hero” with substantial savings; 40 and below get visibly blocky on flat regions and around sharp edges; and 95+ is “near-lossless” with diminishing return on file size and the occasional surprise where the output is larger than the source.

Why the browser’s Canvas is the right encoder. HTMLCanvasElement.toBlob(‘image/webp’, q) lives inside every modern browser and uses the OS or browser’s bundled libwebp. That means there is no JavaScript library to download, no WASM startup cost on first encode, no second copy of the encoder to keep up-to-date with security fixes, and — critically for this tool — no copy of the user’s pixels on any third-party server. The encoder runs the same code that ships with Chrome, Firefox, or Safari and is updated through the browser’s own update channel.

Common use cases

Shrinking a 4 MB iPhone photo before emailing it to a friend whose mailbox cuts off at 5 MB; cutting a 1.8 MB blog hero PNG down to roughly 250 KB so the article above the fold stops stalling on mobile; bringing a multi-megabyte UI screenshot below the corporate bug-tracker attachment ceiling; compressing a folder of product photos for a static-site asset bundle without spinning up cwebp or ImageMagick; or just a one-off “this image is too big, make it smaller” without learning any new tooling. The common shape is “I have one image. I want it smaller. I want to see what I’m losing before I commit.”

Anti-patterns and limits

Compressing screenshots of pure text or small UI as lossy WebP. WebP’s lossy mode is tuned for natural photographs; the prediction and quantisation strategy blurs sharp text edges and colours bleed across hairline UI strokes. For text-heavy screenshots, lossless PNG or lossless WebP (a separate codec, not exposed by this tool in v1) is typically the better path.

Treating WebP as an archival format. Lossy WebP is a forward-only operation. You cannot recover the original JPG bytes from the WebP encode, and re-encoding the WebP again later compounds quality loss the same way repeated JPEG saves do. Always keep the source file as your archival copy; treat the WebP as a derived artefact for delivery.

Pushing the slider to 100 and expecting lossless. toBlob(‘image/webp’, 1.0) is still lossy WebP at the highest quantisation setting — it is not the lossless codec. On already-small inputs (an aggressively-compressed JPG, a flat-colour PNG icon) the result can be larger than the source. When that happens the tool surfaces the percent-savings cell in danger colour with the message “WebP encode is larger than the original at this quality. Try a lower quality, or keep the original.” Download still works in case you want it anyway.

Re-encoding wide-gamut photographs and expecting wide-gamut output. The browser’s Canvas2D context decodes and re-encodes in sRGB, so a Display-P3 or Rec.2020 input is implicitly clipped to sRGB on the way through. The compressed WebP is sRGB. For wide-gamut workflows, use cwebp directly with the relevant ICC profile and -metadata flags.

How to choose a quality

Default ( 80). Photographs, hero images, in-product UI screenshots that include photographs. This is the eye-test sweet spot — most viewers cannot pick the WebP from the source at typical viewing distances, and the file size is meaningfully smaller than the original JPG.

60–70. Acceptable for blog heroes and thumbnails: savings climb sharply versus 80 and the quality drop is modest. Good for above-the-fold mobile delivery where every kilobyte matters.

90+. Marketing and brand imagery where the photographer or designer will look at the file alongside the source. The file is noticeably bigger than 80 for marginal quality gain, but the safety margin is appropriate when the artefact is the point.

< 40. Visible blocking and edge artefacts on most content. Use only for thumbnails or as a deliberate stylistic choice (low-bitrate aesthetic, “compressed-look” web art). The slider is a live preview, so when in doubt, drag it and look.

What the browser does and doesn’t preserve

EXIF metadata is stripped on encode: the Canvas2D pipeline does not pass it through. Camera-orientation tags are applied to the bitmap before encoding (via the imageOrientation: ‘from-image’ option on createImageBitmap), so the output looks correctly upright in any viewer; the WebP file itself carries no orientation tag because the rotation has already been baked into the pixels. ICC profiles, GPS coordinates, camera body and lens information, capture timestamp, and other EXIF fields are all discarded. If you need to keep any of that for a downstream archive or a legal record, use a command-line tool that round-trips metadata.

References

  1. Google Developers. An image format for the Web. The original WebP project page — supports the format’s 2010 Google origin, the VP8 lineage, the replace-JPEG-and-PNG-for-web design goal, and the canonical 0–100 quality scale exposed in libwebp.
  2. Zern, J., Wickramaratne, P., Vandevenne, L., Alakuijala, J., Galligan, F., Yenchik, J., Allred, T., & Lubbers, R. (October 2024). WebP Image Format. IETF RFC 9649. The formal standard — supports the predictive intra-frame coding paragraph (block sizes, residual coding, quantisation), the lossy-vs-lossless-WebP-are-separate-codecs claim, the alpha-channel claim, and the format’s standards-track provenance.

See also: WHATWG HTML Living Standard, HTMLCanvasElement.toBlob and MDN documentation for createImageBitmap (and the imageOrientation option used for EXIF orientation handling).

Related tools