Convert JPG to WebP

Safari cannot write WebP, and that is not a version problem

This page encodes through the browser's own canvas. Chrome, Edge, Firefox, Opera and Samsung Internet all ship a WebP encoder there. Safari does not — not on macOS, not on iOS, in no version released so far. It displays WebP perfectly well. It simply cannot write one.

That matters more than it first sounds, because in practice every browser on an iPhone or iPad renders through WebKit. Chrome for iOS is Safari underneath. There is effectively no browser on an Apple phone that can write a WebP file from a web page.

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. To actually get .webp files, use Chrome, Edge or Firefox on a desktop, or Chrome on Android.

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 negotiate on the server: browsers send an Accept header that names image/webp, so one URL can return WebP to those who ask for it and JPG to those who do not. Send Vary: Accept with it, or a CDN will cache one answer and hand it to everybody.
• Purge the CDN after swapping the files. Stale cached objects are the usual reason a conversion appears to have changed nothing.
• The Core Web Vitals payoff lands in LCP, and only if the image you converted is the one the browser paints first. Converting everything below the fold is tidy, but it will not move that number.

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 — assumes a clean source. A JPG that was already squeezed for the web has spent its detail, so most of what you save on top of it comes out of the picture rather than out of the redundancy.

In practice: a quality-95 export taken to WebP at 82 is dramatically lighter and looks the same. That same shot squeezed to JPEG 60 first and then converted gives you a small file that looks worse than either version you started with. Go back to whatever you keep as the master.

Worth being straight about the encoder too. It is whatever your browser ships, tuned for speed rather than the last few percent. A command-line cwebp or a build-step plugin will usually squeeze a little more out of the same image. The trade is that this runs now, on a whole folder, with no toolchain to install.

When WebP is not the win

The format is a genuine improvement over JPEG for photographic content on a web page. Outside that, the case gets thin fast.

• Logos, icons and flat diagrams: SVG is smaller and stays sharp at any size, and even a PNG can beat lossy WebP on hard edges.
• Images that are already tiny. Below a few kilobytes the gain is noise, and you have added a fallback path for nothing.
• Anything that leaves your site — email attachments, files someone will open in old desktop software. Browsers all read WebP; a lot of other software still does not.
• Images that are simply too large for where they go. Halving the width does more for the byte count than any format change ever will, and that is what Resize image is for.
• If your browser can encode AVIF, an AVIF button appears next to WebP on the format bar. In practice that means Chrome and Edge — Firefox and Safari display AVIF but do not write it from a canvas. AVIF normally goes smaller still, and takes noticeably longer per image.