Lean Image
Open menu

Convert JPG to WebP

You are almost certainly here for a web page — a page-speed report, a Lighthouse warning, or a hero image that takes a beat too long to arrive on a phone. WebP is the right target for that. The saving, though, depends heavily on what your JPG has already been through, and an image that was optimised once already can come back barely smaller. Compare the two numbers before you replace anything.

Loading the optimizer…

Nothing is uploaded. Every image stays in this browser tab —here is how that works.

The headline saving is measured from a different starting point

The comparison quoted everywhere puts two encoders in front of the same original image and measures what each produces. That is not the job in front of you. Your JPG has already been encoded once, possibly by an export preset that squeezed it hard, and the WebP encoder is working from those pixels rather than from the photograph.

In practice a JPG straight out of a camera or a design tool’s maximum-quality export shrinks a great deal, and a JPG that has already been through an optimiser shrinks a little — occasionally not at all. Every card here shows the input size beside the output size. If the output is not smaller, keep the JPG. There is no prize for shipping the newer format.

Set the width before you touch the quality

Almost every JPG on a website is larger than it will ever be drawn. A 4,000-pixel photograph in an 800-pixel column is twenty-five times the pixels the visitor needs, and no encoder setting recovers a mistake of that size.

Work out the widest that image will ever appear, double it for high-density screens, and put the result in max width with the fit mode on contain so the aspect ratio survives untouched. Then choose a quality: 80 is a sensible default for photographs on a page, and 70 is defensible for anything a visitor has to click to see. Do it in the other order and you will spend twenty minutes tuning a slider on an image that was four times too big all along.

Where WebP is still not safe to send

On a web page the question is settled. Away from one, less so, and the failures are quiet rather than loud.

Email is the sharpest edge: several desktop clients, Outlook on Windows in particular, will not render a WebP in a message body, so a newsletter built on them shows a broken image to a slice of the list. Open Graph and Twitter card images are the other one — the scrapers that build link previews are not browsers, and some of them skip a WebP without comment, which turns a shared link into a bare grey box. Keep a JPG for both, and for anything a person will download and open rather than view in a tab.

Doing the whole folder

Select every image at once. Several are processed in parallel across your CPU cores, the queue works through the rest, and there is no file-count limit because there is no server deciding what one should be. Download all returns a single ZIP, written as each file finishes rather than assembled in memory, so a few hundred images will not exhaust the tab.

One thing worth checking after you deploy: your server has to send Content-Type: image/webp. A misconfigured host handing them out as application/octet-stream makes browsers download the file instead of drawing it, and the symptom looks exactly like a broken image rather than like a server problem.

What changes when you convert JPG to WebP

  • A second lossy pass compounds the first — Trade-off

    Decoding a lossy image and re-encoding it lossily runs the whole trade again on pixels that already carry artefacts, and the encoder cannot tell the artefacts from the picture — so it spends bits preserving them. One pass at a sensible quality is far better than three at a high one. If you have the original, convert that instead.

  • WebP cannot exceed 16,383 pixels on a side — Trade-off

    That is a hard limit in the format, not a setting. An image wider or taller than 16,383 pixels — a long screenshot, a panorama, a scanned map — has to be scaled down to fit, and the tool does that automatically rather than failing. If you need the full resolution, JPEG or PNG will take it.

  • WebP is roughly 25–35% smaller than JPEG, and every current browser reads it — Benefit

    WebP is the safe modern default for the web: meaningfully smaller than JPEG at the same visual quality, with real transparency, and supported by every browser released in the last several years. Older desktop software is a different question — some image viewers and editors still will not open one.

  • The detail your JPEG already lost stays lost — Note

    A JPEG has been through a lossy encoder at least once already, and the detail that pass discarded is gone from the file — nothing downstream can reconstruct it. Whatever you convert to inherits that starting point, so the honest goal here is to avoid adding a second helping of loss on top, not to recover the first.

  • Camera and location metadata are not carried over — Note

    EXIF is dropped: the camera model, the exposure settings, the timestamp, and — the one that matters — the GPS coordinates of where the photo was taken. That is a privacy improvement for anything you are about to publish and a loss if you were relying on it for cataloguing. Orientation is the exception: it is applied to the pixels, so the image stays the right way up.

  • Output is sRGB — Note

    Everything this tool writes is in sRGB, the colour space the web assumes. That is what makes the result look the same in a browser, a chat app and a photo viewer without an embedded profile to carry around.

Questions people ask about this conversion

Does WebP work in Safari?

Yes, and has since Safari 14 in 2020, on both macOS and iOS. The browsers that genuinely cannot display one are old enough that they are probably absent from your analytics — Internet Explorer, and Safari 13 and earlier. It is worth checking whether anyone is still using the fallback you are maintaining.

Should I keep the original JPGs?

Yes, somewhere away from the web server. If you re-crop, re-size, or move to a newer format in two years, you want to start from the best file you have rather than from something that has been through a second encoder in the meantime.

Do I still need a picture element with a JPG fallback?

On most sites, no. A plain img tag pointing at a .webp is fine for every browser released in roughly the last six years. The fallback still earns its keep if you have measurable traffic from old devices, or if the same URL gets used in an email or a link preview.

Will converting change how the image looks?

At quality 80 on a photograph, not perceptibly on a screen. What you can sometimes spot is that WebP smooths fine detail rather than breaking it into blocks — grain, fabric texture and distant foliage go soft before they go ugly. Compare at full size when the image is the point of the page.

Related

Other things you can turn a JPG into

Try it with your own file

Drop an image in and see the result before you download anything.