How to Convert Images to WebP, and When Not To

Steps to convert to WebP

1. Add JPG, PNG, GIF, BMP or other supported files to the converter.
2. Open the output format menu and choose WebP. If WebP is missing from the list, your browser cannot write WebP images from a canvas, and the choice appears only in browsers that can. If you do not see it, try another browser.
3. Set the quality. Its default is 90, and for WebP the slider controls how much detail is thrown away. The quality article covers what each range looks like.
4. If the picture will appear on a page narrower than its pixel width, pick a smaller maximum size, for example 1600 or 1280 pixels on the long side.
5. Compare the before and after sizes shown for each file. Keep the WebP only where it is clearly smaller.
6. Download the files, then upload them to your site.

The lossy catch: what you cannot do here

The converter's WebP output is lossy; it has no lossless WebP mode. This matters in two cases. First, a PNG logo with crisp edges will pick up faint softness around edges and slightly shifted colors in flat areas when it goes through lossy WebP, and lowering the quality only makes it worse. The converter has no lossless WebP option and keeps its WebP lossy even with the slider at 100, because Chromium-based browsers would otherwise switch to lossless encoding at exactly that value. For logos, icons and screenshots, keep PNG. Second, converting a JPG to WebP compresses a second time, and the damage from both rounds adds up. If you have the original, convert from that. The WebP format can do lossless in other software, but this tool does not write it.

Transparency survives, since WebP supports it, which is the practical reason to prefer it over JPG for cut-out images in web design. The limits of the WebP format itself are generous, with up to 16383 pixels per side, and the converter applies that limit.

What the savings look like on test images

I encoded a synthetic 1920 x 1080 picture of text on white with a blue rectangle, using the Pillow library. As PNG it was 213,652 bytes. As lossy WebP at quality 90 it was 141,488 bytes, and at quality 80 it was 115,696, a reduction of 34 and 46 percent respectively. On a noisy gradient (which is far harsher than most photographs) the PNG was 2,423,966 bytes and WebP at 80 was 614,714.

The more interesting result concerns JPG. Quality numbers from different encoders do not measure the same thing, so I matched them by peak signal-to-noise ratio on a synthetic picture with soft shapes plus fine texture. JPG at quality 80 gave 98,555 bytes at 42.9 dB; the lowest WebP quality reaching 43.1 dB was 90 and produced 103,528 bytes. In that test WebP saved nothing against JPG. On the text-on-white picture the same matching went the other way: JPG at quality 80 was 230,456 bytes at 39.9 dB, and WebP reached 40.0 dB at quality 47 with 90,952 bytes. Real photographs often behave differently, and encoders vary between browsers, so the lesson is not that WebP is bad but that the saving is something you check, not assume. The converter shows both sizes for exactly this reason.

Choose the pixel size before the format

Pixel dimensions affect file size more than the choice between JPG and WebP, so settle them first. A picture shown 800 CSS pixels wide needs 800 pixels on a normal screen and 1600 on a screen with a device pixel ratio of 2. At 4:3 that is 1600 x 1200 pixels, 1.92 megapixels. Serving a 4000 x 3000 original, 12 megapixels, to the same slot sends 6.25 times as many pixels as the high-density screen can use. Even at 2560 x 1920 (4.9 megapixels) you send 2.6 times too many.

So the practical order is: pick the maximum size menu value that is at least twice your display width, convert, then compare formats. Two sizes, say 1600 and 800, cover most layouts, and the second is for small screens that do not need the larger file. The converter runs every file at one setting, so convert in two passes.

A page-weight example with arithmetic

Say a gallery page loads 24 photos, each 1600 pixels wide, and each is currently 300 KB as JPG. The total image weight is 24 x 300 KB = 7,200 KB, about 7 MB. If your own test shows WebP at the same visual quality coming out 25 percent smaller, the page drops to 24 x 225 KB = 5,400 KB, saving 1,800 KB. For a visitor on a connection that delivers 1 MB per second, that is 1.8 seconds less waiting. If the test shows only a 5 percent saving, 360 KB, conversion is probably not worth the extra step.

The 25 percent figure is a made-up input to show the method, not a promise. The method is what is useful: convert three representative photos, read the sizes, multiply by how many images the page holds.

Rules for deciding

• Photos for your own web pages: convert to WebP at 80 to 90, test the size against the JPG, keep the smaller.
• Logos, icons, diagrams with sharp edges: stay with PNG, because the WebP made here is lossy.
• Images you will edit again, print, or send to others: do not convert. Not every program, printer or chat service reads WebP, as covered in best formats for email and messaging.
• Cut-out pictures that need transparency in a small file: WebP is a good fit and beats a PNG of the same picture.
• Old browsers you must support: serve a JPG or PNG fallback. The website article, best image format for websites, shows the approach.

Common surprises

The WebP is bigger than the source. It happens, particularly with PNG screenshots that are already small or with JPG sources saved at low quality. Keep the original format in that case.

A GIF animation became a single picture. The converter takes only the first frame, as explained in the GIF article.

The savings vanished after you resized. That happens when the original was already small. A 1280 pixel JPG at 150 KB has little left to give; WebP may bring it to 120 KB or may not, and the only way to know is to look at the two sizes.

Colors changed a little. The output is in standard sRGB with no embedded profile, so wide-gamut pictures may look slightly flatter; see the color profile notes. A direct comparison of both formats is in PNG vs WebP.