JPG to WebP
Re-encode a JPG as WebP. The old compression artefacts are picture now, so the WebP encoder spends bits keeping them rather than clearing them.
JPG to WebP puts one lossy encoder's output through a second one. Quality defaults to 80, and a lower number is where the saving is. Every ringing edge and blocking square left by the first pass reads as ordinary detail. WebP has no way to tell one from a real edge, so it pays to keep both.
Questions
Does this remove the compression artifacts already in the JPG?
No. The JPEG is decoded to pixels and the WebP encoder works from whatever is left, ringing and blockiness included, treating it as part of the picture rather than clearing it away.
What do I lose converting to WebP?
More detail, on top of what the JPEG already discarded. This tool writes WebP in lossy mode at a default quality of 80, so it is a second generation of compression. Metadata such as EXIF does not carry across, since the pipeline works on raw pixels only.
Which engine runs this, and where?
jSquash decodes the JPEG with mozjpeg and encodes the WebP with its own WebAssembly encoder. Like every pair in this matrix it runs in Node, on the command line, through MCP and in the browser, with no consent step and no separate download.
What size should I expect?
Usually smaller than the JPG at the default quality of 80, since lossy WebP compresses more efficiently than JPEG at a comparable visual quality. The exact drop depends heavily on the picture.
What is the reverse page?
WebP to JPG runs the opposite direction, decoding the WebP and re-encoding it as JPEG, which becomes a second lossy pass when the source WebP was already lossy.