Your WebP Image Won't Upload: Why, and How to Convert WebP to JPG

You right-clicked an image, chose Save image as, and ended up with a file ending in .webp. Then the form you needed it for refused to take it. A job portal, a print shop, a marketplace listing, some ageing system at work. The wording changes but it's always a variant of unsupported file type, with no hint about what to send instead.

The part that irritates me: you never chose WebP. A server chose it for you, based on a header your browser sent without asking. Now a different server won't accept the result, and you're standing between two machines having a disagreement.

What follows is where that .webp actually came from, why upload forms still turn it away, why renaming the file does nothing, and what genuinely changes inside the picture when you convert it. One of those changes catches people out constantly, and most explanations of it are simply wrong.

Where that .webp file came from (you never chose it)

Image servers don't decide on a format when they store a picture. They decide when they send it. Your browser lists what it can display in the HTTP Accept header, and the server replies with whichever version fits.

You can watch it happen. Here's one Unsplash URL requested twice, with nothing different between the two calls except that header:

$ URL="https://images.unsplash.com/photo-1506905925346-21bda4d32df4?w=400&auto=format"

$ curl -sI -H "Accept: image/webp,image/*" "$URL" | grep -i "^content-type"
Content-Type: image/webp

$ curl -sI -H "Accept: image/jpeg,image/png" "$URL" | grep -i "^content-type"
Content-Type: image/jpeg

Same address, different bytes. Chrome, Firefox and Edge all advertise WebP support, so they all receive the WebP, and Save image as writes whatever arrived. Chrome isn't converting your picture, which is the usual assumption and it's wrong. It's storing what it was handed.

This also means the extension in a URL tells you nothing at all. It's just characters in a string. A link ending in .jpg can return a WebP, and plenty do.

Why upload forms still reject WebP

Browser support stopped being the problem years ago. caniuse currently puts WebP at 96.15% of global users. Chrome has handled it since version 32, Firefox since 65, Edge since 18. Safari was the straggler, partial from 14 and complete from 16. Internet Explorer never did, which still matters if you're feeding files to something that old.

Showing an image and accepting an upload are separate jobs though, handled by different code, usually written years apart. Upload forms run on allowlists. Someone typed jpg, jpeg, png, gif into a validator once, it worked, and nobody has had a reason to reopen it since. Adding a format means touching the validator, then the thumbnail generator, then whatever produces print files at the far end of the pipeline. That ticket rarely gets written.

LinkedIn publishes its list, which makes it a useful example to point at. Their help page for profile media names Adobe PDF, PowerPoint, Word, .jpg/.jpeg, .png and .gif. WebP isn't on it. Desktop software lagged in the same way. Photoshop couldn't open a WebP without Google's separate WebPShop plugin until version 23.2 shipped in February 2022.

The practical rule I'd take from this: anything that stores, prints or forwards your image is far likelier to refuse WebP than anything that merely displays it.

Renaming .webp to .jpg does nothing

Everyone tries this. It never works, and the reason explains a whole category of upload errors.

An extension is a hint for your operating system's file associations. The format lives in the bytes. Every WebP file opens with a RIFF container header carrying the ASCII string WEBP at offset 8:

$ cp photo.webp photo.jpg

$ xxd -l 16 photo.jpg
00000000: 5249 4646 8605 0000 5745 4250 5650 3858  RIFF....WEBPVP8X

$ file photo.jpg
photo.jpg: RIFF (little-endian) data, Web/P image

Renamed, and the system still reads it as WebP, because nothing changed except the label. Any validator worth trusting checks those opening bytes rather than the filename. The ones that don't will cheerfully accept your file and fail somewhere downstream, when a thumbnailer or a printer's software meets bytes it can't parse. A failure at that point is much harder to trace back to its cause, so being rejected at the upload box is genuinely the kinder outcome.

Converting WebP to JPG: what actually changes

A real conversion decodes the WebP to raw pixels and re-encodes them as JPEG. Most tools, including the one on this site, come down to a single ImageMagick call:

magick input.webp -quality 85 -strip -auto-orient output.jpg

Three things happen there beyond the format swap, and only one of them is obvious.

Quality 85 re-encodes the picture. Your WebP was almost certainly lossy already, so this is compression applied to something that has been compressed once before. On a photograph the second pass is hard to spot. On a screenshot full of text, or artwork with hard edges, you'll see softening where the edges were crisp. If you still have the original file, convert from that rather than from the copy you downloaded.

The -strip flag removes metadata. EXIF goes with it: camera body, lens, timestamp, and GPS coordinates if the photo carried any. That's a privacy improvement you get without asking for it, and an annoyance if you needed the capture date. Read anything you care about out of the file before converting.

The -auto-orient flag bakes rotation into the pixels so the picture doesn't appear sideways in software that ignores orientation tags.

Worth being clear about direction. JPEG cannot restore anything WebP threw away, and each round trip costs you a little more. Convert once, at the end, for the destination that actually needs it.

The transparency trap when you convert WebP to JPG

Here's the one that bites people, and the one nearly every guide gets wrong.

JPEG has no alpha channel, so transparency can't survive the trip. What almost everyone writes next is that the transparent areas turn white. They don't, necessarily. What actually happens is that the alpha channel gets discarded and whatever colour values were sitting underneath become visible.

Those hidden values are very often black. I built a transparent WebP and ran the standard conversion over it:

$ magick alpha.webp -quality 85 -strip -auto-orient out.jpg

$ magick out.jpg -format "%[pixel:p{10,10}]" info:
srgb(0,0,0)

Black. A logo that looked correct on your white page arrives as a black rectangle with your logo sitting in the middle of it. When I repeated the test on a file whose transparent region had white pixels beneath the alpha, the identical command produced white. The outcome depends entirely on what your image editor happened to leave under the invisible parts, which is why it varies between files and why nobody can honestly promise you white.

Two things follow. Open the converted JPG and look at it before you send it anywhere, because this failure is invisible until it lands on someone else's screen. And if you control the conversion, set the background yourself instead of hoping:

magick alpha.webp -background white -alpha remove -alpha off -quality 85 out.jpg

If the image needs real transparency at the other end, JPEG is the wrong target completely. Convert to PNG and keep the alpha channel.

Converting WebP to JPG without installing anything

Check your own machine first. Current versions of Photoshop, Preview on macOS and most up-to-date image viewers will open a WebP and save it back out as a JPEG, which saves you a trip.

When you're on a locked-down work laptop or someone else's computer, a browser tool covers it. You can convert WebP to JPG in the browser and get the file back without installing anything. Ours handles one file at a time up to 10 MB, does the work on the server, and applies the same quality 85 encode described above. For forty product photos, a desktop tool or a one-line ImageMagick loop will beat it comfortably.

When WebP is the file you should keep

Don't convert out of reflex. If the image is headed for your own website, WebP is the better file, and Google's published figures are the ones to work from: lossless WebP runs 26% smaller than PNG, and lossy WebP is 25 to 34% smaller than a comparable JPEG at an equivalent SSIM quality index. Transparency costs roughly 22% extra bytes in lossless mode, and still lands near a third of the size of the PNG equivalent.

Publishing platforms caught up a while back. WordPress has accepted WebP uploads since version 5.8 in July 2021, although lossless WebP needs the host running Imagick rather than LibGD.

Going the other way is a reasonable thing to want too. If you're preparing images for a site you run, taking finished JPEGs and producing WebP copies for the web will cut your page weight noticeably.

Which format goes where

If one thing sticks from all this, make it the diagnosis. The rejection isn't your mistake and the file isn't corrupt. A server picked a format your browser was happy to take, and the next system along has an allowlist written in 2015. Convert once, open the result to check the background didn't come out black, then send the JPG. Keep the WebP for the site you control, because that's the one place it really is the better file.