Convert JPG to WebP

How to convert JPG to WebP

1. Choose one or more JPG images — drag them in or use the file picker.
2. Set the WebP quality if you want a smaller file or sharper output.
3. Download the WebP — a single file, or a zip if you converted several at once.

WebP re-encodes JPEG’s 8×8 blocking — it cannot undo it

A JPEG’s pixels are already the output of one lossy pass — cut into 8×8 blocks, DCT-transformed and quantised — so decoding hands back the damaged pixels, not the originals. Lossy WebP is a VP8 key frame, the still-image half of the video codec Google acquired with On2 and released on 30 September 2010, and its 16×16 macroblocks, intra-prediction modes and 4×4 transforms only re-describe what they are handed. None of them reverses a quantisation that already happened; the blocking is baked into the input the second encoder receives.

Google’s comparison put WebP 25–34% below JPEG at matched SSIM, but it encoded PNG originals once into each format; an existing JPEG has already spent part of that margin. The launch-day announcement, re-encoding about a million mostly-JPEG images to WebP, reported an average 39% reduction instead — so savings on a JPEG source vary widely rather than settling on one figure, and they narrow as the setting rises. A small, heavily compressed JPEG can even come back larger than it began.

One loss no quality figure prevents: the VP8 bitstream stores lossy WebP as 4:2:0, one colour sample for every 2×2 block of pixels. Plenty of JPEGs are not subsampled — Photoshop keeps full-resolution 4:4:4 chroma at its top quality settings — and re-encoding one of those to lossy WebP discards three-quarters of its colour samples. That loss appears only in the WebP, never in the JPEG it came from, showing first on saturated red edges and small coloured text against a contrasting background.

A JPEG never records the quality it was saved at, so there is nothing to match

A setting of 92 is a WebP encoder’s number, not the JPEG’s. That 0–100 quality scale is a convention of the encoder — libjpeg’s, for one — not part of the format: ITU T.81 defines quantisation tables and no quality dial at all, and WebP’s own 0–100 (the tool exposes 40–100) maps onto different quantisation that was never calibrated against the source. A JPEG stores those tables, never the figure that produced them, so any quality number read back from one is estimated backwards from the tables.

That argues for keeping the setting near the top rather than chasing a source quality that was never written down. Two lossy passes that decompose the image differently cannot cancel: JPEG quantises an 8×8 DCT, while VP8 re-quantises the decoded pixels with a different 4×4 DCT basis and its own intra prediction. Even where the block seams line up — VP8’s 4×4 edges fall on every JPEG 8×8 boundary — the two transforms measure different coefficients, so the second rounding cannot undo the first.

So no setting reproduces the source; each one only re-describes its already-quantised pixels. Raising the WebP figure past the JPEG’s effective quality spends bytes copying the 8×8 seams and ringing more faithfully, not recovering detail the first pass discarded — which is why the file can keep growing while the picture stops improving. The high-frequency AC coefficients the JPEG quantiser already rounded to zero are simply absent from the pixels VP8 receives, so no WebP number can encode a detail that the first codec deleted.

Questions