Convert WebP to JPG on Mac

Three routes. Every macOS release since Big Sur decodes WebP, so Preview, Quick Look, Safari and sips all open these files without help.

# a folder of them
mkdir -p jpg
sips -s format jpeg *.webp --out jpg/

# one file, explicit quality 0-100 (the default is equivalent to 75)
sips -s format jpeg -s formatOptions 90 photo.webp --out photo.jpg

# PNG works the same way if you need the alpha channel kept
sips -s format png logo.webp --out logo.png

Four WebP files in one glob produced four JPEGs in one pass. The PNG route works too: the same photograph came out at 450,390 bytes as a PNG against 71,285 as a JPEG, which is the usual PNG tax on photographic content.

Preview is the graphical route: open the WebP, File → Export As…, choose JPEG, use the Quality slider. Select several thumbnails in one window and the menu item becomes Export Selected Images….

Finder handles it with no Terminal at all, either through an Automator Quick Action built on Change Type of Images, or through Smol’s own Finder Quick Action, which converts a selection in place from the right-click menu.

Because WebP is simply the better codec, and converting away from it costs you what it was saving. This is the part most pages on this subject skip, and it reframes the whole job: you are converting for compatibility, not for size.

The screenshot row is the worst and the most instructive. That file was lossless WebP, 20,196 bytes of pixel-perfect UI. As a quality 75 JPEG it is 114,953 bytes and damaged, with ringing around every letterform. Converting it is a straight downgrade on both axes, and if the destination can accept PNG, PNG is the better landing spot at roughly the same size.

Smol’s numbers are larger again because it converts at a higher internal fidelity than sips does. That is a deliberate default rather than a bug, and the same pattern shows up in PNG to JPG. If you want small rather than faithful, ask for compression with an explicit quality rather than a conversion.

Because ImageIO ships a WebP decoder and no WebP encoder, and that asymmetry is the one real limitation here. Reading is free. Writing is not available at any price:

$ sips -Z 400 photo.webp --out small.webp
Error: Can't write format: org.webmproject.webp
Error 13: an unknown error occurred
$ echo $?
13

Exit 13, no file. Note what that command was actually asking for: not a conversion, just a resize with the format left alone. Any operation that ends in a WebP file fails, so sips cannot resize, rotate or re-save a WebP in place. It can only read one and write something else.

That makes the built-in tools a one-way street. WebP to JPEG or PNG, as often as you like. Anything to WebP needs third-party code, and the PNG to WebP guide covers which tools and what they cost you, including why lossless WebP beat lossy WebP on a retina screenshot.

Four things, all verified, none of which prints an error you would notice.

An animated WebP loses every frame but the first. An 8-frame, 480 × 270 animation went in at 25,882 bytes and came out as a single 5,454-byte JPEG. Exit code 0. No warning, no mention of the other seven frames. If the file is animated you want a video container instead, and ffmpeg -i anim.webp anim.mp4 is the shorter path. Smol does not paper over this one: handed the same animated file it failed with “A required component is missing. Try reinstalling smol.” while the three still WebP files in the same job converted normally. A confusing message for an unsupported input, and better than silently binning the animation.

Transparency gets filled in, and the tools disagree about the color. The alpha WebP converted with sips came out white where it had been transparent. The same file through Smol came out black. JPEG has no alpha channel, so something has to go there, and which something you get depends entirely on the tool. Convert to PNG instead if the alpha matters.

In-place conversion keeps the wrong extension. Running sips -s format jpeg shot.webp with no --out rewrites shot.webp with JPEG bytes and leaves the name alone. It prints Warning: Output file suffix should be jpg and exits 0. You now have a file that lies about itself, which web servers and asset pipelines will happily mislabel.

A missing output directory is not an error. --out nodir/x.jpg with no nodir present exits 0 and writes a single extension-less file called nodir containing the JPEG. mkdir -p first.

A browser, almost always. WebP is what most sites now serve to Chrome and Safari, so “Save Image As…” hands you a .webp file even when the page looked like it was showing a photograph. The problem only surfaces later, when you attach it to something that predates the format: an older Office build, a print shop’s upload form, a CMS with a fixed allow-list, a client who wants a JPEG.

There is a nastier variant. Plenty of sites serve WebP bytes from a URL ending in .jpg, so you save what looks like a JPEG and nothing will open it. macOS sniffs content rather than trusting the name, which makes this easy to diagnose and easy to fix:

$ file mystery.jpg
mystery.jpg: RIFF (little-endian) data, Web/P image, VP8 encoding, 768x512

$ sips -g format mystery.jpg
  format: webp

# and it converts anyway, name notwithstanding
$ sips -s format jpeg mystery.jpg --out real.jpg

We ran that against WebP bytes wearing .jpg, .png and an uppercase .WEBP, and all three produced the same valid 71,285-byte JPEG. The extension is decoration. file and sips -g format tell you what you actually have.

For one file, use sips or Preview. One command, no install, and on this particular conversion the built-in encoder produces a smaller JPEG than we do: 71,285 bytes against 115,651 on the same photograph. If the only goal is a file the recipient can open, macOS already wins.

For animated WebP, use ffmpeg. We fail on it outright and sips silently discards the animation. Neither is acceptable when the motion is the point.

To go the other way, use cwebp or a build tool. Nothing in macOS writes WebP, and for web output sharp in a Node build or cwebp in a Makefile belongs in the pipeline rather than in a desktop app.

Where Smol is worth $29: a folder of a few hundred files saved off the web in mixed WebP, AVIF, PNG and HEIC that all have to come out as JPEG at one consistent setting, from the Finder right-click menu, with metadata stripped and nothing leaving the machine. Sixty images converted in 2.6 seconds in our batch test, against 12.55 seconds for the equivalent shell loop. One purchase, no subscription.

Related: PNG to WebP, the direction macOS cannot do, AVIF to JPG, TIFF to JPG, and every format Smol reads and writes.