Convert JPG to WebP

If the WebP button is grayed out, you get PNG

This page encodes through the browser's own canvas, so writing WebP is the browser's job. On load, the page asks it for a one-pixel test image in WebP and checks what comes back. Displaying WebP is a different ability, and a browser can have one without the other.

That is why the page keeps no list of browsers that can or cannot do it: lists age, and the test does not. Reload the page in whatever browser you have at hand and look at the button.

The page checks before you start rather than failing halfway. If the encoder is missing, the WebP button is disabled, the output falls back to PNG, and a message tells you it happened. PNG is lossless, so that fallback can come out heavier than the JPG you started with; the card shows it.

Converting is the easy half — serving it is the other half

A folder of .webp files does nothing for your page speed until the HTML points at them, and renaming an extension in an img tag is not a migration.

• Serve both: a picture element with a WebP source and a JPG img fallback lets each browser choose, and costs you nothing in markup complexity.
• Or let the platform choose: Shopify's help center (checked September 2026) says it detects which formats the visitor's browser supports and serves the best one available. On WordPress, uploads of .webp work since 5.8 if the server's image library supports the format.
• If the site sits behind a CDN, purge it after swapping the files, or visitors keep receiving the old cached copies.
• The Core Web Vitals metric involved is LCP, and web.dev's field data tempers expectations: most sites with poor LCP spend less than 10% of that time downloading the image. Converting trims bytes; it rarely rescues a slow page by itself.

Convert from the original, not from the copy already on your server

The number WebP is known for — Google's own study puts it at 25 to 34 percent smaller than JPEG at matching SSIM — was measured from clean PNG sources. A JPG that was already squeezed for the web has spent detail it cannot get back, and the conversion compresses what is left.

Every additional JPEG encoding adds loss, even at a higher quality setting than the original: Jon Sneyers showed it on Cloudinary's blog in 2016, and found that WebP suffers from it even more. Go back to whatever you keep as the master.

Worth being straight about the encoder too. It is whatever your browser ships, and this page controls nothing in it beyond the quality number. It is not cwebp, the command-line encoder Google's study used, so do not expect the study's figures to the decimal. The trade is that this runs now, on a whole folder, with no toolchain to install.

When WebP is not the win

The measured gain is for photographic content on a web page. Outside that, the case gets thin fast.

• Logos, icons and flat diagrams: for icons, MDN's advice is the SVG version whenever one exists; for logos, diagrams and line art, lossless encoding.
• Images that are already tiny. Below a few kilobytes the gain is noise, and you have added a fallback path for nothing.
• Anything that goes out by email: caniemail's 2021 tests have Outlook for Windows 2007–2019 not displaying WebP, and Gmail turning it into a JPG. Desktop software is a program-by-program question.
• Images that are simply too large for where they go. Halving the width leaves a quarter of the pixels; the Max width (px) field on this page does that before encoding.
• AVIF is not an option here today. The AVIF output button only appears when the browser reports that it can encode AVIF, and in our tests of September 2026 Chrome could not. For AVIF you need another encoder.