Convert WebP to JPG

This is one of the few conversions people arrive at irritated. You right-clicked a picture, saved it, and got a `.webp` — a format you did not choose and possibly had not heard of. Then Word would not insert it, or the photo printing site rejected it, or the upload form said the file type was not supported. The image is perfectly good. It is simply in a format built for browsers, and you have left the browser.

The reason it happened is straightforward. Most websites now serve photographs as WebP because it is roughly a third smaller than JPG for the same visual quality, which makes pages load faster. When you save an image, you get what the browser downloaded. Every current browser reads WebP without trouble, which is exactly why the problem only shows up the moment the file goes somewhere else.

The list is shorter than it was and still awkward: older versions of Office and Photoshop, several desktop image viewers, quite a few upload forms, and a good number of photo printing services. These are not going to be updated on your schedule.

Converting to JPG is the pragmatic answer — thirty years old, universally supported, and never the reason an upload fails. If you only need to look at the file, most operating systems will now open a WebP in their built-in viewer; if you need to send it, convert it.

Expect the file to get bigger, and do not read that as a fault. WebP genuinely compresses better, so the same picture needs more space as a JPG. You are trading file size for compatibility, deliberately, and for a single image about to be attached to something it is a trade worth making without thinking about it.

It only becomes a problem in bulk. If you are converting a folder of images for a website rather than for one email, the WebP was the better file and the right move is usually to fix whatever is refusing it.

There is a small cost. The WebP was already compressed once, and JPG compresses the decoded picture again. At the default setting this is not something you can see, but it is real, and it compounds if you keep converting back and forth. Convert once, keep the result, and if the image is going to be edited or blown up afterwards, raise the quality setting first.

One case to watch: WebP can store transparency and JPG cannot. If the image you saved has a transparent background — a logo, a cut-out product shot — those areas have to be filled with something, and white is the default. You can change the fill colour in the settings, but if the transparency is the point, convert to PNG instead and keep it.

The conversion runs in your browser. Nothing is uploaded, which for an image you have just saved off somebody else's website is simply the sensible way round.

Image generators export WebP by default, and the places those images end up frequently do not accept it: client portals, marketplace listings, print upload forms, job applications, and a great many content management systems still reject the format outright. The rejection message rarely explains itself, which is how people arrive here.

JPG is the answer when the picture is finished and simply needs to be accepted somewhere. If it is instead going into further editing or an upscaler, convert to PNG rather than here — JPG discards detail on the way, and doing that before the work rather than after it is the one ordering that cannot be undone.

Most people arrive here with one image. If you have arrived with a folder — a client sent an archive, or a site export produced WebP throughout — drop it a hundred files at a time. They convert one after another and come back as a single ZIP.

A hundred to a drop and 100 MB a file are the two caps; there is no queue, no account and no daily allowance. A hundred large photographs at once will still make an older laptop work for it, so convert in batches of fifty and nothing is lost.

Around 85 is the value where a photograph looks unchanged and the file stays reasonable. Above it the size climbs quickly and nobody sees the difference; below it, haloes start to appear along hard edges.

Raise it if the JPG is going to be edited or enlarged afterwards, because that would be a third round of compression on a picture that has already had two. Lower it only when you are aiming at a specific upload limit — there is nothing to gain from a smaller file that nothing requires to be smaller.

WebP can carry EXIF, but often does not, and an image saved out of a browser has usually been stripped of it by the site that served it. In most cases there is nothing here to lose.

Where there is something, it does not survive. The WebP is decoded to pixels and the JPG is written from those pixels, so an EXIF block, an XMP packet and any coordinates are all left at that boundary — not removed by a setting, simply never carried. The JPG you download states nothing about where or when the picture was taken.

So nothing further is required if removal was the point. If it was not, note the direction of the loss before you delete anything: the WebP is the copy that still has the date, and once it is gone the JPG cannot be asked for it.

WebP can hold an animation; JPG can only ever hold one frame. Rather than quietly keeping the first frame and dropping the rest, the decoder behind this page reads still images only — there is no component that unpacks an animation into frames — so an animated WebP is refused with a readable error and nothing gets converted.

That is rarely what anyone wanted anyway. If a single frame is genuinely enough, open the WebP in a browser, pause it on the frame that matters and screenshot it — that still image converts to JPG here without issue. There is no conversion on this site that keeps the motion, so a WebP that has to stay animated should stay a WebP.