Compress-or-Die ist zurück
Zehn Jahre lang war compress-or-die.com für viele Entwickler die erste Adresse, wenn ein Bild kompromisslos klein werden musste: keine Presets, keine Blackbox, sondern echte Kontrolle über Quantisierungstabellen, Chroma-Subsampling, Trellis-Quantisierung und getrennte Luma- und Chroma-Qualität. Gründer Christoph Erdmann hat das Projekt von 2016 an allein betrieben, bis er es 2026 nicht mehr weiterführen konnte. Jetzt ist die Seite zurück, neu aufgebaut von Timo Strauß, einem Freund Erdmanns, der das Tool nach eigener Aussage selbst seit zehn Jahren nutzt und es nun Compressor für Compressor neu schreibt.
Das Ergebnis ist mehr als eine reine Fortführung. Verarbeitet wird weiterhin ausschließlich clientseitig per WebAssembly, kein Byte verlässt den eigenen Rechner, kein Account, keine Kosten. Für ein Tool, das täglich große Mengen an Bilddaten verarbeitet, ist das die konsequenteste Umsetzung von Datensparsamkeit, die sich denken lässt: keine Serverlast, keine Übertragung, keine Speicherung fremder Bilder, nur der Browser der Nutzerin selbst.
Unterstützt werden aktuell JPEG, PNG, GIF, WebP und SVG, mit vollem Zugriff auf genau die Feineinstellungen, die anderswo hinter fertigen Presets verschwinden. Das ist kein Selbstzweck: Wer Luma- und Chroma-Qualität getrennt regeln kann, nutzt aus, dass das menschliche Auge Helligkeitsunterschiede viel feiner auflöst als Farbunterschiede, und kann so bei gleicher wahrgenommener Qualität spürbar mehr Bytes einsparen, als es ein einzelner Qualitätsregler je erlauben würde. Trellis-Quantisierung reduziert Blockartefakte bei gleicher Dateigröße zusätzlich. Genau diese Stellschrauben fehlen den meisten kostenlosen Online-Kompressoren, die stattdessen nur einen groben Schieberegler von „klein“ bis „gut“ anbieten und den Rest verschweigen. Dazu kommen zwei weitere Werkzeuge in Entwicklung: ein Analyze-Tool, das Metadaten in Bilddateien sichtbar macht, und ein Repair-Tool für beschädigte PNGs.
Bei den Formaten selbst ist als Nächstes JPEG XL geplant. Und genau bei dieser Priorität würde ich widersprechen.
Wer heute Entwicklungszeit in ein neues Format steckt, optimiert damit für eine Nische, die überwiegend aus Safari-Nutzern besteht, während AVIF längst der pragmatische Standard für kleinere Dateien bei breiter Kompatibilität ist. Das Format lässt sich mit Squoosh von Google kostenfrei erstellen und optimieren
Das schmälert nicht, was Timo Strauß hier leistet, im Gegenteil: Ein Tool mit dieser Fülle an ehrlichen, ungeschönten Optionen ist selten genug, dass man es unterstützen sollte. Aber wer die Formatwahl nach tatsächlicher Reichweite trifft und nicht aus der Apple-Brille betrachtet, würde AVIF vor JPEG XL priorisieren.
Für die tägliche Praxis ändert das wenig: Wer heute exportiert, greift ohnehin zu AVIF, wo es die Zielgruppe erlaubt, und zu WebP als breit kompatiblem Fallback. JPEG XL bleibt bis auf Weiteres ein Format für Safari-lastige Zielgruppen und für alle, die es aus Prinzip früh unterstützen wollen, nicht aus Reichweitengründen. Compress-or-die bleibt trotzdem, wie schon zu Erdmanns Zeiten, das Werkzeug, das einem keine Entscheidung abnimmt, sondern sie erst möglich macht. Genau das ist es wert, dass ein Projekt wie dieses weiterlebt, auch wenn die eigene Formatliste noch nicht ganz mit der Realität der Browserstatistiken übereinstimmt.