sips WebP on macOS: 64 Formats In, 22 Out

Four scripts in this repo turn blog posts into images, and every one starts with the same line: /tmp/imgenv/bin/python. That is a Pillow virtualenv living in /tmp, which is exactly as durable as it sounds — macOS empties that directory on its own schedule and the image pipeline stops until I rebuild it. Since macOS ships an image converter, sips, in every install, I asked whether it could replace the venv.

The answer is no, and the reason is a single row in a table Apple ships but almost nobody prints. Our thumbnails are WebP. sips reads WebP and cannot write it.

The table: 64 in, 22 out

sips --formats prints the read/write list for the binary you actually have. On this site’s Mac mini (Mac16,10, macOS 26.4.1 build 25E253, sips-316) it returns 64 rows, of which 22 are marked Writable. The other 42 are read-only: sips will open them and convert them to something else, and will never produce one.

Thirty of the 42 read-only entries are camera RAW — Canon, Nikon, Sony, Fuji, Leica, Hasselblad and friends — which makes sense and matters to almost nobody. Strip those out and the read-only list you actually care about is twelve entries long:

com.apple.pict               pict
com.microsoft.cur            --
com.sgi.sgi-image            sgi
org.nema.dicom               dcm
org.webmproject.webp         webp
public.avci                  avci
public.avis                  --
public.heif                  heif
public.jpeg-xl               jxl
public.mpo-image             mpo
public.radiance              pic
public.svg-image             svg

The asymmetries are worth memorising. AVIF is writable but AVCI is not. HEIC is writable but HEIF is not. WebP and JPEG XL are readable only. Two writable rows have no file extension at all, just --.

Measured, not inferred

A table is a claim, so I ran every format against a 400×225 PNG — a flag that advertises support is not the same thing as support, which is the same lesson the bundled rsync on macOS taught me earlier this week.

$ sips -s format webp src.png --out t.webp
Error: Can't write format: org.webmproject.webp
$ echo $?
13

Same for jxl. Meanwhile avif, heic, jpeg, png, tiff, gif and pdf all wrote cleanly at exit 0. The read direction is genuinely fine too: a Pillow-made in.webp of 11,784 bytes reports format: webp under sips -g format and converts out to PNG (104,728 B) and JPEG (24,964 B) without complaint. One-way street.

One trap while probing this: piping sips into tail made a failing conversion look like a success, because a pipeline returns the exit status of its last command. Check $? on the bare command.

Extension names are not format names

Two failures here have nothing to do with capability and everything to do with string lookup:

$ sips -s format jpg src.png --out b.jpg
Error: Can't write format: (null)

$ sips -s format tif src.png --out b.tif
Error: Can't write format: com.canon.tif-raw-image

The first is merely annoying: jpg is not in the table, so it resolves to nothing. The second is the interesting one. tif is in the table — as com.canon.tif-raw-image, a read-only Canon RAW type that happens to claim the tif extension. Ask sips for tif and it hands you Canon RAW and then refuses to write it. The format you wanted is spelled tiff.

The man page has been wrong for fifteen years

Here is the part that made me stop and check a date. man sips on this machine documents the format property as taking jpeg | tiff | png | gif | jp2 | pict | bmp | qtif | psd | sgi | tga. Eleven values. I ran all eleven: eight work, three fail — pict, qtif and sgi, with exits of 13. The list also omits fourteen formats that do work, including heic and avif, the two most useful things this tool can produce on a modern Mac.

Then I found a question on Ask Different from 15 May 2011 titled “Sips not working with pict, qtif and sgi files.” Same three formats. The asker quotes the man page list, and it is character-for-character the list I just read in 2026. The only thing that changed in fifteen years is the wording of the error: it said Error: Unsupported output format com.apple.pict then, and says Error: Can’t write format: com.apple.pict now. The one answer on that thread, from 2019, gets it right: “sips itself has been updated but the man page remained the same.”

The in-place trap

Leave off --out and sips does not error. It converts the file where it lies:

$ sips -s format jpeg inplace.png
$ file -b inplace.png
JPEG image data, JFIF standard

134,474 bytes of PNG became 25,858 bytes of JPEG, the filename still says .png, and the original is gone. Exit 0, no warning — in a build script, a silent data loss bug plus a served file whose extension lies to every browser that requests it.

Quality options, and one that fails

-s formatOptions takes low, normal, high, best or a percentage, and JPEG walks up it predictably: 7,255 / 14,437 / 25,858 / 110,972 bytes. AVIF follows the same pattern at 2,852 / 7,398 / 15,777 — and then dies:

$ sips -s format avif -s formatOptions best src.png --out q.avif
Error: Unable to write image to file /var/folders/nw/.../583C8BAA-...
Error 13: an unknown error occurred

A writable format that fails at its maximum quality setting, in the temporary staging file rather than the destination. best and 100 both do it; high is fine.

sips can draw. That was not the blocker.

I expected to close this out with “and anyway sips is only a converter, it cannot composite text the way our card renderer does.” That is wrong. sips --js runs JavaScript with a real HTML Canvas 2D context, an Output(context, name[, type]) object and a write queue. I drew a card — fillRect background, an accent bar, fillText in Helvetica — and it wrote a 6,735-byte PNG. AVIF and JPEG came out too.

Then I pointed the same three lines at w.webp:

$ sips --js c7.js
addToQueue returned
$ echo $?
0
$ ls w.webp
ls: w.webp: No such file or directory

Exit 0. Zero bytes on stderr. No file. The command-line path at least tells you Can’t write format and returns 13; the JavaScript path accepts the request, reports nothing, and writes nothing. If you build a thumbnail pipeline on sips --js and your output format is WebP, it will appear to work forever.

One more sharp edge there: sips.arguments contains raw argv including flags, so a loop over it will happily pass --js as a format type. That does not return an error either — it throws NSInternalInconsistencyException … Invalid parameter not satisfying: tag != nil and aborts the process with exit 134.

What I actually did

The venv stays. Our cards are written by Pillow at WEBP quality=82, method=6, which is a setting I arrived at by measuring, and there is no path from sips to that file. For reference, at nominal 82 on this source Pillow’s WebP is 12,058 bytes against 19,196 for sips AVIF and 18,184 for HEIC — different encoders on different quality scales, so read that as what each tool produces at its default-ish setting, not as equal visual quality.

What changed is that I stopped treating Pillow as the fragile part. The fragile part is that the venv lives in a directory macOS is entitled to empty; the fix is to move it. If you are generating OG images and can live with AVIF or HEIC output, sips genuinely can do it with no dependencies at all — just print --formats first and check your target is on the right side of the table.

A commenter on the 2023 Hacker News thread about sips asked how to throttle it while converting “100 or 1000 PNGs to Webp”. Thirty-two comments, 192 points, and nobody mentioned that the conversion he was planning cannot happen. That is the whole reason this post exists.

The scheduler, the renderer and make-thumbnails.py itself are in the Playbook ($12) if you want the working pipeline rather than the list of things that do not work.

Method and sources: every number here was measured on 2026-09-24 on this site’s Mac mini (Mac16,10, macOS 26.4.1 build 25E253) against the stock /usr/bin/sips, which reports itself as sips-316. The source image was /System/Library/CoreServices/DefaultDesktop.heic resampled to 400×225; the WebP input was produced by Pillow, since nothing on the machine could make one otherwise. Format support was taken from sips --formats and then verified by attempting every conversion rather than trusting the table, with exit codes read from the bare command. The man page quoted is the one installed on this machine and mirrored here; the 2011 report and its 2019 answer were pulled through the StackExchange API, and the Hacker News thread through the Algolia items API, rather than from search snippets.