WebP to JPG, and JPG to WebP: Which Direction You Need, and Why

Two completely different people search for WebP conversion, and they need opposite things.

The first saved an image from a website, ended up with a .webp file, and cannot open it in the program they need. They want to go from WebP.

The second was told their site is slow because the images are too heavy. They want to go to WebP.

Both are right. Which one you are determines everything about what to do next.

What WebP is, briefly#

Google published WebP in 2010 as a replacement for JPEG and PNG in a single format. It supports both lossy and lossless compression, has an alpha channel for transparency, and can hold animation.

The headline number is that it typically reaches the same visual quality as JPEG in 25 to 35 per cent fewer bytes. Against PNG for images with flat colour and transparency, the saving can be much larger.

For most of its first decade WebP was held back by patchy browser support, which is why it took so long to appear everywhere. That constraint is gone: every browser in current use displays it, and has for years. What has not caught up is desktop software and upload forms, which is the entire source of the first problem.

Going from WebP: when the file will not open#

If you have a WebP that something refuses to accept, the format is not obscure — your application is simply older than 2020, or its developers never added the extension to an allowed list. Common offenders:

• Older versions of Photoshop, before native support arrived
• Microsoft Office insert-picture dialogs on older installs
• Print and photo-lab upload forms
• Job application portals, government forms, and anything with a fixed list of accepted extensions
• Desktop photo organisers and older editing suites

Convert to JPEG if it is a photograph. Convert to PNG only if it has transparency or is a screenshot or diagram with hard edges — for a photograph, PNG will produce a file several times larger for no visible gain.

Expect the JPEG to be bigger than the WebP was. This surprises people who assume conversion is a neutral operation. It is not: you are moving from an efficient format to a less efficient one, and the file grows accordingly. A 400 KB WebP might land at 550 KB as a JPEG at comparable quality. That is the price of compatibility.

You are also paying a small quality cost, because both formats are lossy and you have now encoded twice. One round is not visible. Repeated rounds are, so convert from the original rather than from a copy of a copy.

Going to WebP: when your site is slow#

The other direction is a straightforward win, and it is one of the few genuine free lunches in web performance.

Images are usually the heaviest thing a page loads. Switching from JPEG to WebP at the same visual quality removes roughly a third of that weight, with no layout change, no code change beyond the file reference, and no perceptible difference to the reader.

That weight matters directly. Largest Contentful Paint — the Core Web Vitals metric that measures how long the biggest visible element takes to render — is an image on most pages. A third less to download is a third less waiting, and it is felt most by exactly the readers who are already having the worst time: someone on a phone on a poor connection. Our guide on image optimisation and Core Web Vitals goes through which decisions move which metric.

The one thing to be careful about is keeping the originals. Convert copies. If AVIF or something after it becomes the sensible default in three years, you want to re-encode from the highest-quality source you have, not from a WebP that has already been through one lossy pass.

What about AVIF?#

AVIF is generally smaller than WebP at the same quality, sometimes substantially. Its costs are slower encoding and thinner support in older software and build tooling.

For a website, the strongest arrangement is AVIF with a WebP or JPEG fallback, served through a <picture> element so each browser takes the best format it can read. For a file you are emailing to a person, AVIF is currently the format most likely to prompt the same "it will not open" conversation that brought you here about WebP.

Choosing a format, in one table#

Doing the conversion without uploading anything#

Browsers can decode WebP natively and re-encode to JPEG or PNG through the canvas API. That means the whole conversion can happen inside the page, on your own processor, with nothing transmitted anywhere.

This matters more than it sounds. Most online converters upload your image to a server, convert it there, and hand back a link — so a photograph you wanted in a different format has been copied to a company you know nothing about. There is no technical reason for that; it is a choice the tool made.

Our image compressor converts between JPEG, PNG and WebP in either direction, in the browser, and shows the resulting size before you download so you can see what the conversion cost. It also resizes in the same pass, which is worth doing if the file is going to a web page — the format change is the smaller of the two savings if your image is four times larger than the space it will be displayed in.

The short version#

Work out which direction you are going. Going from WebP is a compatibility fix, it will make the file bigger, and JPEG is nearly always the right destination. Going to WebP is a performance improvement, it is close to free, and the only discipline required is keeping your originals.

If you want the reasoning behind each format rather than a rule, our comparison of JPG, PNG, WebP and AVIF works through what each one assumes about your image and what happens when the assumption is wrong.