Convert PNG to WebP on Mac

Because there is no encoder to call. ImageIO publishes two lists, one of formats it can read and one of formats it can write. On macOS 27.0 (build 26A428) that is 62 readable identifiers and 22 writable ones. Print them yourself:

swift -e 'import ImageIO
let w = CGImageDestinationCopyTypeIdentifiers() as! [String]
let r = CGImageSourceCopyTypeIdentifiers() as! [String]
print("webp readable:", r.contains("org.webmproject.webp"))
print("webp writable:", w.contains("org.webmproject.webp"))'

That returns readable: true and writable: false. Safari, Preview, Quick Look and sips all open WebP without complaint, and none of them can produce one. Every WebP on your Mac was made by third-party code: libwebp, Chrome, Pixelmator, Sketch, a build tool, or an app that bundles one of those.

Worth contrasting with AVIF, where public.avif is on both lists. Apple built an AVIF encoder and did not build a WebP one, which is a reasonable read of where the format war landed. It is also why AVIF conversion on a Mac needs no tools at all.

Five PNGs, three content types, one encoder. Lossy figures use cwebp -q 75 -m 6; lossless uses cwebp -lossless -z 9. PSNR is measured against the source PNG, where higher is better.

Three separate lessons sit in that table, and they point in different directions.

A photograph stored as PNG is the single biggest win available. Kodak 23 went from 557,596 bytes to 22,456, a 96% cut, because PNG was never meant to hold a photograph and WebP was. If your site has photographs in PNG files, that is not a conversion job, it is a bug, and converting is worth roughly 25 times the bytes.

Screenshots land around 68–70% whichever mode you pick. The interesting part is that lossless is free: at 1× the two modes finished 110 bytes apart, and at 2× lossless won by 10,466 bytes.

Line art is the one case where lossy is clearly ahead, 17,664 against 30,922. Anti-aliased edges over large flat fills are exactly what the lossy encoder’s prediction modes handle well, and at 39.38 dB with an SSIM of 0.99869 the damage is not visible at any reasonable zoom.

Almost every article on this subject skips lossless WebP, which is odd, because it is a genuinely different codec inside the same container and it beats PNG on everything PNG is good at.

It is lossless in the strict sense. Decoding the three lossless files above and comparing them pixel by pixel against the sources gave a maximum channel difference of 0 on all three. Not “visually identical”. Identical.

Use it when any of these are true:

• The image is a screenshot, a UI export, a chart, or anything with text in it
• The image needs an alpha channel and must stay crisp at the edges
• The asset is a source file that will be edited again later
• You are replacing PNGs on a site and cannot risk a visible regression

The obvious objection is “why not just optimize the PNG instead”. Measured: re-encoding the three non-photographic fixtures with ImageMagick at maximum compression and an adaptive filter made every one of them larger, 232,992 to 238,207, 102,986 to 107,446, and 69,383 to 70,869. Chrome and Pillow already emit well-compressed PNGs. Lossless WebP is 3.6 times smaller than the best PNG on the retina screenshot. The format is the win, not the effort setting.

# lossless, maximum effort: right for screenshots and UI
cwebp -lossless -z 9 shot.png -o shot.webp

# lossy, right for photographs and line art
cwebp -q 75 -m 6 photo.png -o photo.webp

# a whole folder
for f in *.png; do cwebp -quiet -lossless -z 9 "$f" -o "${f%.png}.webp"; done

Drop the folder on Smol, or right-click it in Finder if you have installed the Quick Action. Five PNGs converted to WebP in 1,105 ms on the M2 Pro, pixel dimensions preserved, no upload.

Compare those against the cwebp table and the trade is clear. Smol converts conservatively: bigger files, higher fidelity. Its 1× screenshot came out at 56,816 bytes and 45.33 dB, which sits above cwebp -q 90 (44,948 bytes, 44.89 dB). If you want the aggressive numbers you have to ask for them.

Here is the trap, and it is worth stating plainly because we tested it: the image quality setting does not apply to the convert operation. Running the same conversion with quality forced to 40 produced a byte-identical 56,816-byte file. Convert changes the container at a fixed internal quality. Quality belongs to compression, so the route that actually gives you a dial is to compress with WebP as the output format:

Three files, 1,319 ms. Those numbers are competitive with hand-tuned cwebp, and they come out of a drag and drop. The same distinction between converting and compressing runs through compressing images on a Mac and is worth internalising once.

For a build pipeline rather than a folder, Smol exposes both operations over an MCP server that Claude Code, Codex and Google Antigravity drive directly, which is how every figure in this article was collected.

For photographs, AVIF beats WebP and it is not close. For screenshots and UI assets, lossless WebP is frequently the better answer, because AVIF’s lossless mode is not widely tuned for that content and lossy AVIF puts ringing on text.

The pragmatic setup is to serve both and let the browser choose, which costs nothing because the picture element was designed for exactly this:

<picture>
  <source srcset="shot.avif" type="image/avif">
  <source srcset="shot.webp" type="image/webp">
  <img src="shot.png" alt="Batch overview" width="1440" height="900" loading="lazy">
</picture>

Keep the width and height attributes. They cost two attributes and they prevent the layout shift that a lazy-loaded image otherwise causes.

If you want lossless WebP, use cwebp -lossless. Smol writes lossy WebP only, and on the retina screenshot that is the difference between 139,212 bytes and 64,484 pixel-perfect ones. libwebp is free, it is the reference implementation, and for screenshot-heavy work it is simply the right tool.

If you are converting images as part of a web build, use sharp in Node or cwebp in a Makefile. Conversion belongs in the build, where it is versioned and reproducible, not in a desktop app someone has to remember to run.

If it is one image, one time: Pixelmator Pro and Figma both export WebP, and so does any browser-based tool you already have open.

Smol is worth the money for the case those three do not cover. A folder of mixed PNG, JPEG and HEIC that needs to come out as WebP at a consistent quality, with metadata stripped, from Finder, on a machine where client work is not allowed to leave the building. That is the job, and if it is your job, Smol is a one-time $29.

Related: AVIF to JPG, HEIC to PNG, batch HEIC to JPG, and the complete list of formats Smol reads and writes.