Squoosh CLI, imagemin, sharp oder PiPic: der Bild-CLI-Check 2026

Frag herum, wie man Bilder im Terminal komprimiert, und du bekommst immer dieselben Antworten: Squooshs CLI, imagemin, sharp oder einen Einzelformat-Encoder wie pngquant. Die meisten dieser Empfehlungen stammen von 2023 oder früher. Also haben wir einen Nachmittag lang nachgeprüft — am 7. August 2026, auf einem ganz normalen Laptop, macOS mit Apple Silicon, Node 22.14, das aktuelle LTS. Alles frisch installiert und über denselben kleinen Testordner laufen lassen: ein PNG, ein JPEG, ein bereits einmal optimiertes JPEG und zwölf Bytes reiner Text, umbenannt in broken.jpg. In echten Bildordnern landet immer irgendetwas Seltsames.

Noch bevor irgendetwas lief, erzählen die Zeitstempel der npm-Registry schon eine Menge:

@squoosh/cli        0.7.3    Jan 2023   "no longer maintained"
imagemin            9.0.1    Mar 2025
imagemin-cli        8.0.0    May 2024
imagemin-mozjpeg   10.0.0    Dec 2021
imagemin-webp       8.0.0    Jan 2023
sharp              0.35.3    Jul 2026
sharp-cli           5.2.0    Jun 2025

Squoosh CLI stürzte ab, bevor es das erste Bild anfasste

Wir haben mit @squoosh/cli angefangen, weil es am häufigsten empfohlen wird. Es ist der Kommandozeilen-Ableger von Squoosh, Googles Web-App — die Web-App ist großartig und wird weiter gepflegt. Die CLI nicht. Ihr letztes Release erschien im Januar 2023, und die eigene readme sagt es unverblümt: "Project no longer maintained." (Projekt wird nicht mehr gepflegt.)

Die Installation läuft durch. Der Befehl startet. Und sobald man ihn etwas komprimieren lässt, stirbt er auf der Stelle — sein WebAssembly-Loader versucht, einen lokalen Dateipfad per fetch() zu laden, und das heutige Node verweigert das:

code: 'ERR_INVALID_URL',
input: '…/@squoosh/lib/build/imagequant_node-a4aafbae.wasm'
— exit 1

Den JPEG-Pfad haben wir auch probiert. Gleicher Absturz, gleiche Stelle. Wer dieses Tool heute installiert, kann kein einziges Bild damit komprimieren. Tutorials empfehlen es weiter, und Modelle, die mit diesen Tutorials trainiert wurden, ebenfalls. Niemand korrigiert den Rat, weil niemand mehr da ist.

imagemin machte seine Arbeit — und log bei der Textdatei

imagemin machte den besseren ersten Eindruck. Das Kernpaket hatte im März 2025 ein Release, und mit unseren echten Bildern funktionierte es einfach — drei Dateien rein, "3 images minified", fertig.

Zwei Dinge störten unterwegs. Erstens die Installation. Vier Pakete, fünf Deprecated-Warnungen, und npm audit fand 37 Schwachstellen im nagelneuen Projekt — 1 davon critical. Der Grund ist schnell gefunden: Die eigentliche Kompression steckt in Plugins pro Format, und die Plugins sind alt. Das JPEG-Plugin erschien zuletzt im Dezember 2021, WebP im Januar 2023, und für AVIF gibt es gar kein offizielles Plugin.

Zweitens die falsche Datei:

Minifying images
1 image minified
— exit 0

Es kopierte die zwölf Bytes Text unangetastet in den Ausgabeordner und zählte sie als komprimiertes Bild. Exit 0. Mit bloßem Auge fällt das sofort auf. Einem Skript nicht. Ein Agent, der "1 image minified, exit 0" liest, meldet Erfolg und macht mit der nächsten Aufgabe weiter.

An sharp ist nichts auszusetzen — genau das ist die Falle

sharp selbst ist in Bestform. Release im Juli 2026, seit einem Jahrzehnt das Rückgrat der Bildverarbeitung auf npm, und beim Thema Wartung schlägt es alles andere in dieser Liste mühelos.

Aber sharp komprimiert keine Ordner. Es ist eine Bibliothek; das Skript schreibst du. Also haben wir das Skript geschrieben, das alle schreiben — ein paar Zeilen, alles auf Standardwerten — und es laufen lassen:

photo.jpg            88556 -> 38879   smaller
photo-optimized.jpg  26659 -> 32050   LARGER
— exit 0

Das frisch exportierte JPEG wurde wunderbar kleiner. Das bereits optimierte kam 20% größer zurück, und unser Skript speicherte es trotzdem, weil wir ihm nie gesagt haben, es zu lassen. Das ist kein Fehler in sharp. Die Qualitätszahl, welche Dateien man überspringt, was passiert, wenn die Ausgabe wächst, wie man das Ergebnis meldet — sharp überlässt all das dem, der das Skript schreibt. Und das bist meistens du um sechs Uhr abends, oder dein Agent. Genau dieses improvisierte Skript haben wir in Gib deinem Coding-Agent einen Bildkompressor beschrieben; diesmal haben wir ihm beim Scheitern zugesehen.

Eine Zahl spricht gegen uns

Das gehört laut gesagt: Mit Standardeinstellungen produzierte imagemins mozjpeg das kleinste JPEG des Tages — 26.659 Bytes gegenüber 31.774 bei pipic. Die Standard-Qualitätsstufen unterscheiden sich von Tool zu Tool, Bytezahlen allein entscheiden also nichts; dafür bräuchte es einen Qualitätsvergleich, und den haben wir nicht gemacht. Dieser Test handelt von Verhalten, nicht von Kompressionsraten. Aber die Zahl, die nicht für uns spricht, verstecken wir nicht.

Wo wir schon fair sind: Die klassischen Einzelformat-Encoder — pngquant, oxipng, cjpeg, cwebp, avifenc — sind solide, und sie sind ohnehin das, was alles oben Genannte innen drin verpackt. Wer nur in einem Format lebt, kann sie bedenkenlos nehmen (für AVIF erklärt die AVIF-Seite, wann sich der Wechsel lohnt). Vier Formate bedeuten allerdings vier Installationen, vier Flag-Dialekte und ein Wrapper-Skript, das ab jetzt dir gehört.

Derselbe Ordner durch pipic

Wir haben der pipic-CLI das identische Verzeichnis gegeben, kaputte Datei inklusive:

$ pipic ./img -o ./out --json          # paths shortened
{"file":"…/img/broken.jpg","status":"error","before":12,"after":0,"saved":0,"error":"UPSTREAM_ERROR: Compression service error"}
{"file":"…/img/icon.png","status":"ok","before":13897,"after":7449,"saved":6448}
{"file":"…/img/photo-optimized.jpg","status":"skipped","before":26659,"after":26659,"saved":0,"error":"not smaller — copied as-is"}
{"file":"…/img/photo.jpg","status":"ok","before":88556,"after":31774,"saved":56782}
{"file":"…/img/photo.png","status":"ok","before":302850,"after":104288,"saved":198562}
— exit 1

Halte das gegen die Fehler von oben, Punkt für Punkt. Die Textdatei kommt als error mit Begründung zurück, und der ganze Lauf endet mit Exitcode 1 — ein Skript weiß also, dass etwas schiefging. Das bereits optimierte JPEG steht auf skipped und bleibt unverändert, Begründung inklusive, statt still um 20% zu wachsen. Und jedes Bild bekommt seine eigene JSON-Zeile mit echten Vorher-nachher-Bytes, auf der ein Skript direkt verzweigen kann.

Der Preis ist real, also hier ganz offen. Jedes andere Tool in diesem Artikel läuft auf deinem Rechner. pipic ist ein Dienst: Dateien werden hochgeladen, im Speicher komprimiert und sofort gelöscht — nie gespeichert — aber sie verlassen deinen Computer. Die CLI braucht ein Konto, mit 100 Bildern im Monat gratis und 5.000 für $9 im Pro-Tarif. Der Web-Kompressor bleibt davon unberührt kostenlos, unbegrenzt und ohne Konto. Und wenn deine Regel lautet „Bilder verlassen diese Maschine nicht", nimm die lokalen Tools — diese Regel steht über allem anderen in diesem Artikel.

Was das Konto dir kauft, ist die Kehrseite jedes Befunds oben: kein wasm-Loader, der vor sich hin verrottet, kein Plugin-Bausatz zum Selberschrauben, keine improvisierten Qualitätsentscheidungen, und eine Ausgabe, auf die sich Automatisierung wirklich verlassen kann.

Zusätzlich haben wir einen getrennten Benchmark mit 12 lizenzierten PNG-, JPEG-, WebP- und AVIF-Eingaben ausgeführt. Methode, alle 72 Rohläufe, Medianwerte, der beibehaltene Fehler und die Sichtprüfungen sind öffentlich. Dieser Datensatz vergleicht PiPic Agent CLI 1.0.6 mit sharp 0.35.3. Der Ordnertest oben untersucht das Verhalten im Betrieb und erstellt keine Rangliste nach Komprimierungsrate.

Mach den Ordnertest selbst

Die ganze Methode passt in einen Nachmittag, und unseren Zahlen musst du nicht glauben. Erst nachsehen, ob noch jemand zu Hause ist:

npm view @squoosh/cli time.modified

Dann einen Ordner anlegen, ein bereits optimiertes Bild und eine kaputte Datei hineinlegen und dein Kandidaten-Tool darüberlaufen lassen. Saubere Bilder komprimiert jeder gut; die verraten dir nichts. Bei den seltsamen Dateien zeigt ein Tool sein Urteilsvermögen — und seltsame Dateien bekommt irgendwann jeder Ordner.