Kostenloser Online-Bildkompressor

So funktioniert's

1. Wählen Sie ein oder mehrere Bilder oben aus oder ziehen Sie sie dorthin.
2. Passen Sie den Qualitätsregler an (niedriger = kleinere Datei, stärkere Komprimierung).
3. Bilder werden in Ihrem Browser komprimiert · nichts wird hochgeladen.
4. Laden Sie komprimierte Bilder einzeln oder alle auf einmal herunter.

Warum Bilder komprimieren?

Große Bilder verlangsamen Websites, erhöhen die Absprungrate und schaden Ihrem Google-Ranking. Die Komprimierung von Bildern reduziert die Dateigröße um 50-80% bei minimal sichtbarem Qualitätsverlust. Das ist unerlässlich für Webentwickler, Blogger, Online-Shops und alle, die Inhalte online veröffentlichen. Kleinere Bilder sparen außerdem Bandbreite auf Mobilgeräten und verbessern die Core Web Vitals-Werte.

Was «Bildkompression» tatsächlich bedeutet

Bildkompression umfasst zwei grundlegend verschiedene Operationen, die sich denselben Namen teilen. Verlustbehaftete Kompression, verwendet von JPEG und verlustbehaftetem WebP, verwirft Bilddaten, die das menschliche Auge wahrscheinlich nicht bemerkt (feine Abstufungen in Schatten, hochfrequentes Rauschen, Chroma-Unterabtastung gegenüber der Helligkeit, um die menschliche Wahrnehmung auszunutzen). Die Ausgabe ist kleiner als die Eingabe, kann aber nicht bitgenau rekonstruiert werden. Verlustfreie Kompression, verwendet von PNG, GIF, TIFF-LZW und verlustfreiem WebP, codiert die genauen Pixeldaten kompakter mit Algorithmen wie DEFLATE (LZ77 + Huffman). Die Ausgabe ist kleiner, und die Dekompression reproduziert das Original Byte für Byte. Welches das richtige ist, hängt vom Bild ab: Fotografien vertragen Verlust hervorragend, weil ihr Inhalt voller Textur ist, die das Auge nicht auf Pixelebene verfolgt; Logos, Bildschirmfotos und Grafiken mit scharfen Farbübergängen verlangen verlustfreie Kompression, weil jeder Pixel beabsichtigt ist.

Qualitätseinstellungen in einem JPEG-Kompressor (der Schieber dieses Werkzeugs, 10-100 %) steuern die Quantisierungstabellen, die nach dem DCT-Schritt angewendet werden. Bei Qualität 100 runden die Tabellen kaum Frequenzkoeffizienten; bei Qualität 50 runden sie aggressiv. Höhere Qualität bedeutet größere Dateien mit feineren Details; geringere Qualität bedeutet kleinere Dateien mit sichtbaren Blockartefakten in flachen Bereichen. Der Standard von 60 % liegt im Idealbereich für Webnutzung: typischerweise eine Dateigrößenreduzierung von 50 bis 80 % ohne wahrnehmbare Veränderung auf einem typischen Bildschirm. Für Druck oder große Displays auf 80-90 % erhöhen. Für Vorschaubilder oder E-Mail-freundliche Versionen funktionieren 30-50 % gut.

Für PNG gilt der Qualitätsschieber im üblichen Sinne nicht, weil PNG immer verlustfrei ist. Was dieses Werkzeug tatsächlich bei PNG-Eingaben tut, ist einen stärkeren DEFLATE-Durchlauf zu fahren, als die meiste Authoring-Software (Photoshop, Affinity, Sketch) standardmäßig nutzt; das spart typischerweise 5 bis 25 % an Dateigröße ohne jede Pixeländerung. Das Format-Dropdown erlaubt außerdem die Umwandlung von PNG zu JPEG oder WebP, was die Verlustfreiheit gegen eine viel kleinere Datei eintauscht, aber Transparenz bei JPEG-Ausgabe verliert und (für fotografische Inhalte) die Verlustfreiheitsgarantie bei WebP. Die Option Maximalbreite verkleinert Bilder während der Kompression: Ein 4000 Pixel breites Foto, das auf 1920 Pixel verkleinert wird, spart 75 % an der reinen Pixelzahl, bevor überhaupt eine Kompression läuft, und das addiert sich zur Qualitätsreduktion.

Wie dieses Werkzeug unter der Haube funktioniert

Die Kompressions-Engine ist browser-image-compression von Donald Wong (GitHub: Donaldcwl/browser-image-compression, MIT-Lizenz). Es ist eine reine JavaScript-Bibliothek, etwa 95 KB minifiziert, die drei Browser-Primitive umhüllt: die File-API zum Lesen der Bytes, die Canvas-API (oder OffscreenCanvas, wo verfügbar) zum Dekodieren, Skalieren und erneuten Codieren von JPEG/WebP-Bildern, und UZIP (eine kleine DEFLATE-Bibliothek), um PNG ohne Canvas zu verarbeiten. Wenn Sie ein Bild ablegen, übergibt der Browser die Bytes an die Bibliothek; die Bibliothek wählt den Weg basierend auf Eingabeformat und gewünschter Ausgabe.

Für JPEG- und WebP-Eingaben ist der Weg: zu einem Canvas dekodieren, optional auf die konfigurierte Maximalbreite skalieren, dann canvas.toBlob(mimeType, Qualität/100) aufrufen. Der eingebaute JPEG- oder WebP-Codierer des Browsers übernimmt die eigentliche Quantisierung und Huffman-Codierung. Die Qualität ist Ihr Schiebewert geteilt durch 100, übergeben als zweites Argument. Für PNG-Eingaben, die als PNG erhalten bleiben, überspringt die Bibliothek Canvas vollständig (ein Umweg über Canvas würde die verlustfreien Daten unnötig neu rastern) und führt stattdessen UZIP direkt über die IDAT-Blöcke der PNG-Datei mit maximaler Kompressionsanstrengung aus. Deshalb ist die PNG-zu-PNG-Kompression hier wirklich verlustfrei: Die Pixeldaten werden nie dekodiert und neu codiert, nur die DEFLATE-Verpackung wird enger gezogen.

Wenn OffscreenCanvas unterstützt wird (moderne Chrome, Edge, Safari, Firefox), läuft die schwere Decodieren-Skalieren-Codieren-Arbeit in einem Web Worker, und der Haupt-UI-Thread bleibt reaktionsfähig. Sie können einen Stapel von 20 Fotos ablegen und weiter durch die Seite scrollen, während jedes verarbeitet wird. Auf älteren Browsern fällt die Bibliothek auf den Haupt-Thread zurück, was zwar funktioniert, aber die Seite während großer Aufgaben blockiert. Die gesamte Pipeline läuft in Ihrem Tab. Die Bibliothek wird beim ersten Besuch einmalig von einem CDN geladen (etwa 95 KB minifiziert) und danach im Cache vorgehalten. Dateiinhalte verlassen den Browser nie. Öffnen Sie den Netzwerk-Tab der DevTools, während Sie einen Stapel komprimieren, und Sie sehen das einmalige Bibliothek-Holen, aber sonst nichts.

Eine kurze Geschichte der Bildkompressionsformate

• DCT, 1972-1974. Nasir Ahmed schlug 1972 die diskrete Kosinustransformation als Bildkompressionsverfahren vor; der formale Algorithmus wurde 1974 mit T. Natarajan und K. R. Rao veröffentlicht. Diese eine mathematische Transformation liegt unter jeder JPEG-, MPEG- und H.26x-Videodatei der Welt heute.
• JPEG, 1992. Die Joint Photographic Experts Group (1986 gegründet) standardisierte JPEG 1992 als ITU-T T.81 / ISO/IEC 10918-1. 8x8-DCT-Blöcke, YCbCr-Farbraum mit optionaler Chroma-Unterabtastung, auf das menschliche Sehen abgestimmte Quantisierungstabellen. Das Format, das das fotoreiche Web möglich machte.
• PNG, 1996. Bei der IETF als RFC 2083 geschaffen, um GIF zu ersetzen, nachdem Unisys' LZW-Patentansprüche das offene Web bedroht hatten. DEFLATE-Kompression (LZ77 + Huffman), immer verlustfrei, volle Alpha-Transparenz, ohne Patentlast. Die 3. Ausgabe der Spezifikation (W3C, 2023) fügte HDR, APNG-Animation und EXIF-Metadaten offiziell hinzu.
• WebP, 2010. Google veröffentlichte WebP als Standbildformat, das auf der Intra-Frame-Codierung des VP8-Videocodecs basiert. Verlustbehaftetes WebP ist 25-34 % kleiner als JPEG bei vergleichbarer visueller Qualität; verlustfreies WebP ist etwa 26 % kleiner als PNG. Die Verbreitung dauerte ein Jahrzehnt; bis 2026 unterstützen über 96 % der Browser weltweit das Format.
• AVIF, 2019. Die Alliance for Open Media veröffentlichte AVIF als Standbild-Variante des AV1-Videocodecs. Etwa 50 % kleiner als JPEG bei vergleichbarer Qualität. Die Browser-Unterstützung liegt jetzt über 95 %, aber die Encoder-Unterstützung in alltäglichen Authoring-Werkzeugen (Photoshop, Word, Slack) hinkt. Squoosh und ImageMagick können heute AVIF erzeugen; die meisten Kameras und Telefone nicht.
• HEIC, 2017. Apple übernahm HEIC auf Basis von HEIF/H.265 als Standard-Fotoformat des iPhone. Etwa halb so groß wie das entsprechende JPEG. Lizenzgebührenpflichtig, daher selten im offenen Web ausgeliefert. Die meisten Online-Uploader (auch dieses Werkzeug) akzeptieren HEIC nur nach einer Desktop-Umwandlung zu JPEG; diese Umwandlung ist der Alltagsworkflow, um Telefonfotos an einen Nicht-Apple-Empfänger zu senden.

Unterstützte Formate

• JPEG · Am besten für Fotos und komplexe Bilder. Verlustbehaftete Komprimierung mit einstellbarer Qualität.
• PNG · Am besten für Grafiken, Logos und Bilder mit Transparenz.
• WebP · Googles modernes Format bietet kleinere Dateien als JPEG/PNG bei vergleichbarer Qualität.

Echte Kompressions-Workflows

• Bilder für Blog und Website. Ein 2-MB-JPEG direkt vom Telefon vs. ein 250-KB-komprimiertes JPEG: für das menschliche Auge auf einem typischen Bildschirm identisch, aber die kleinere Datei lädt etwa 8x schneller. Die Core-Web-Vitals-Werte (LCP) verbessern sich direkt. Die meisten Seiten mit mehreren Fotos sehen die größten Lighthouse-Performance-Gewinne aus der Bildkompression, nicht aus der JavaScript- oder CSS-Optimierung.
• Uploads in sozialen Medien. Instagram, Twitter, Facebook, LinkedIn komprimieren beim Upload alle Bilder mit eigenen Algorithmen erneut. Vorher zu komprimieren gibt Ihnen die Kontrolle darüber, was geopfert wird; rohe Fotos hochladen überlässt diese Entscheidungen der Plattform, oft mit sichtbarer Verschlechterung.
• E-Mail-Anhänge. Die meisten Anbieter begrenzen Anhänge auf 25 MB pro Nachricht (Gmail, Outlook, Apple Mail). Einen Ordner Fotos von rund 50 MB auf rund 10 MB zu komprimieren erlaubt es, alles in einer einzigen E-Mail zu senden, statt auf mehrere Sendungen aufzuteilen oder auf einen Cloud-Share-Link umzusteigen.
• Produktfotos im E-Commerce. Produktkataloge mit hunderten oder tausenden Fotos verursachen hohe CDN-Bandbreitenkosten und langsame Seitenaufrufe. Die gesamte Bibliothek zu komprimieren reduziert beides. Shopify-, Etsy- und Amazon-Verkäufer komprimieren routinemäßig vor dem Upload, um Hosting-Kosten zu senken und das Suchranking zu verbessern.
• Bildschirmfoto-reiche Portfolios. UI-Design-Portfolios sind PNG-lastig, weil Bildschirmfotos scharfe Farbübergänge haben, in denen JPEG-Artefakte sichtbar wären. PNG-zu-PNG mit engerem DEFLATE spart typischerweise 10-20 % ohne Pixeländerung, nützlich für Designer-Portfolioseiten, die schnell bleiben müssen, ohne Renderqualität zu opfern.
• Archivierungs-Verkleinerung. Ein 12-Megapixel-Foto vom Telefon ist für ein Familien-Sharing-Album, das ohnehin nur auf Bildschirmen betrachtet wird, übertrieben. Auf 4 Megapixel bei 80 % Qualität skalieren: Das Ergebnis sieht auf jedem Gerät, das es jemals sehen wird, identisch aus, und das Archiv schrumpft auf ein Fünftel der ursprünglichen Größe. Die Originale bleiben sicher auf der Quellenfestplatte; die komprimierten Versionen wandern in die Freigabe oder das Backup.

Häufige Fallstricke und was sie bedeuten

• Ein JPEG mehrfach neu zu komprimieren verschlechtert es. Jeder JPEG-Speichervorgang führt den DCT-Quantisierungsschritt erneut aus und verliert Detail, das Sie nie wieder zurückgewinnen. Die Verluste sind beim ersten Durchgang subtil und beim dritten oder vierten offensichtlich. Komprimieren Sie immer aus der höchsten Qualitätsquelle, die Sie haben (die ursprüngliche Kameradatei, der Export aus Ihrem Designwerkzeug), nicht aus einem zuvor komprimierten JPEG, das Sie letzte Woche gespeichert haben. Wenn Sie Anpassungen vornehmen müssen, behalten Sie eine Master-Kopie in PNG oder TIFF.
• PNG zu JPEG verliert die Transparenz. JPEG hat in der Formatspezifikation einfach keinen Alpha-Kanal. Jeder transparente Pixel wird beim Konvertieren von PNG zu JPEG zu reinem Weiß (oder was Ihr Encoder ersetzt). Für Logos, Symbole, Bildschirmfotos mit transparentem Hintergrund oder jede Grafik mit einem Alpha-Kanal: in PNG bleiben oder zu WebP wechseln, beide bewahren Transparenz.
• JPEG zu PNG macht die Datei größer. Die DEFLATE-Kompression von PNG ist großartig bei sanften Verläufen und großen einfarbigen Flächen, schrecklich bei den hochfrequenten Rauschmustern, die JPEG-Kompression zurücklässt. Ein JPEG in PNG umzuwandeln verdoppelt oder verdreifacht die Dateigröße oft, ohne Qualitätsgewinn. Wenn Sie verlustfreie Daten aus einem JPEG benötigen, sind Sie schon zu spät: Die ursprünglichen Informationen sind weg. Die Umwandlung macht nur Sinn, wenn Sie ausdrücklich die Transparenz von PNG brauchen oder ein Werkzeug, das kein JPEG akzeptiert.
• EXIF-Metadaten werden standardmäßig entfernt. Die Bibliothek browser-image-compression verwirft beim erneuten Komprimieren standardmäßig EXIF-Metadaten (Kamera-Informationen, GPS-Koordinaten, Aufnahmedatum, ICC-Farbprofil). Für Webnutzung ist das meist ein Feature (durchgesickerte GPS-Koordinaten sind ein echtes Datenschutzproblem). Für Fotografen, die mit intakten Metadaten archivieren, ist dieses Werkzeug nicht das richtige; verwenden Sie einen EXIF-bewussten Desktop-Kompressor wie ImageOptim oder jpegtran mit der expliziten Option «Metadaten erhalten».
• Farbprofile können verloren gehen. Ein eingebettetes ICC-Farbprofil (sRGB, Adobe RGB, ProPhoto) sagt Bildschirmen, wie die Pixelwerte zu interpretieren sind. Eine Canvas-basierte Neucodierung kann das eingebettete Profil verwerfen und die Ausgabe als sRGB kennzeichnen. Für gewöhnliche Bildschirmnutzung ist das in Ordnung, weil ohnehin fast alles sRGB ist. Für Druckvorstufenarbeit, farbverwaltete Fotopräparation oder Lieferungen mit weitem Farbraum verwenden Sie ein farbbewusstes Werkzeug (Photoshop «Exportieren als», Affinity, RawTherapee), das Profildaten explizit erhält.
• Sehr große Bilder können einen mobilen Browser-Tab zum Absturz bringen. Ein Bild zu Canvas zu dekodieren benötigt RAM proportional zu seinen Maßen: Ein 24-Megapixel-Foto (6000x4000 Pixel) braucht allein für den RGBA-Pixelpuffer etwa 96 MB, plus Arbeitsspeicher des Encoders. Mobile Geräte mit 4 GB RAM können den Tab vom Betriebssystem beendet bekommen, bevor das Codieren fertig ist. Verkleinern Sie die Eingabe oder verwenden Sie für sehr große Fotos einen Desktop-Browser.

Datenschutz: Bilder bleiben auf Ihrem Gerät

Jeder Cloud-Bildkompressor (TinyPNG, Compressor.io, Optimizilla, die Bildwerkzeuge von Smallpdf, der Kompressions-Endpunkt von Pixlr, die Dutzenden «Bild online komprimieren»-Dienste) lädt Ihre Datei auf die Server des Betreibers hoch, führt deren Kompressionsalgorithmus aus und gibt das kleinere Bild als Download zurück. Die Datenschutzimplikationen sind nicht trivial, weil Fotos routinemäßig identifizierbare Inhalte enthalten: Gesichter, im Hintergrund sichtbare Adressen, Bildschirmfotos interner UIs oder vertraulicher Dokumente, Fotos von Kindern, Fotos in privaten Räumen aufgenommen. Die meisten Betreiber veröffentlichen Datenschutzerklärungen, die zusagen, Uploads innerhalb einer oder zwei Stunden zu löschen und beim Transport zu verschlüsseln, und die größten (TinyPNG, Smallpdf) führen ISO/IEC-27001-Zertifizierungen. Sie haben starke wirtschaftliche Gründe, diese Zusagen einzuhalten. Aber «in einer Stunde gelöscht» ist nicht «nie gesehen». In dieser Stunde befindet sich der Bildinhalt in der Infrastruktur des Betreibers, zugänglich für jeden Prozess oder Menschen mit entsprechenden Rechten, und sichtbar in Protokollen und Backups gemäß der jeweils anwendbaren Aufbewahrungspolitik.

Dieser Kompressor lädt niemals etwas hoch. Die Bibliothek browser-image-compression läuft vollständig in Ihrem Browser-Tab; die Bild-Bytes werden über die File-API gelesen, in JavaScript verarbeitet (oder in einem Web Worker, falls OffscreenCanvas verfügbar ist), und die komprimierte Ausgabe wird in denselben Tab als herunterladbares Blob zurückgegeben. Sie können das Fehlen eines Uploads überprüfen, indem Sie die Entwicklerwerkzeuge des Browsers im Netzwerk-Tab öffnen, bevor Sie einen Stapel komprimieren: Es werden keine Anfragen mit Ihrem Bildinhalt abgesetzt. Der einzige Netzwerkverkehr ist das einmalige Laden der Bibliothek (~95 KB) vom CDN beim ersten Besuch, danach bleibt die Bibliothek im Cache. Schalten Sie den Browser nach dem Laden der Seite in den Flugmodus, und der Kompressor arbeitet weiter mit lokalen Dateien. Für Fotos mit etwas Sensiblem (Gesichter, Orte, interne Bildschirmfotos) ist der Browser-seitige Kompromiss eindeutig wertvoll.

Wann ein anderes Werkzeug die richtige Wahl ist

• Stapelverarbeitung von 500+ Bildern in einer skriptgesteuerten Pipeline. Verwenden Sie sharp in Node.js (die kanonische serverseitige Bildbibliothek), ImageMagick oder GraphicsMagick auf der Kommandozeile oder Pillow in Python. Diese Werkzeuge bewältigen Tausende von Dateien ohne Browser-Speichergrenzen und laufen aus CI-Jobs, Deploy-Hooks oder Cron-Aufgaben.
• Strikte Verlustfreiheitsgarantien mit nachweisbarer Bit-Gleichheit. Für PNG zu PNG ist dieses Werkzeug echt verlustfrei, weil UZIP die Pixeldaten nicht anfasst. Für Workflows, die kryptografische Verifikation verlangen (medizinische Bildgebung, juristische Beweismittel), verwenden Sie ein Desktop-Werkzeug wie ImageMagick mit explizitem `-define png:compression-level=9` und SHA-256-Verifikation der decodierten Pixeldaten.
• Druckqualitäts-Farbprofilerhaltung. Adobe Photoshop, Affinity Photo oder RawTherapee für Druckvorstufenarbeit mit ICC-Profilerhaltung, Soft-Proofing und CMYK-Ausgabe. Browserbasierte Kompression kann farbverwaltete Workflows nicht garantieren, weil Canvas in sRGB arbeitet und eingebettete Profildaten verwerfen kann.
• AVIF-Ausgabe für Kompression der nächsten Generation. browser-image-compression gibt im Jahr 2026 kein AVIF aus. Für AVIF-Codierung im Browser verwenden Sie Squoosh (ebenfalls von Google, ebenfalls clientseitig); für AVIF auf der Kommandozeile verwenden Sie avifenc aus libavif. AVIF erzeugt Dateien, die bei vergleichbarer Qualität etwa 50 % kleiner als JPEG sind, aber der Encoder ist rechenintensiv (10x langsamer als JPEG-Codierung).

Häufig gestellte Fragen

Verringert die Komprimierung die Bildqualität?

Bei der Standardqualität von 60% sehen die meisten Bilder nahezu identisch mit dem Original aus, sind aber 50-80% kleiner. Passen Sie den Regler an, um die richtige Balance für Ihre Anforderungen zu finden.

Gibt es eine Dateigrößenbeschränkung?

Jedes Bild kann bis zu 50 MB groß sein. Da die Verarbeitung in Ihrem Browser erfolgt, können sehr große Dateien je nach Gerät einen Moment dauern.

Werden meine Bilder auf einen Server hochgeladen?

Nein. Die gesamte Komprimierung erfolgt lokal in Ihrem Browser. Ihre Bilder verlassen niemals Ihr Gerät, was dies vollständig privat und sicher macht.

Welche Qualitätseinstellung sollte ich verwenden?

Für die Webnutzung sind 60-70% ideal. Für Druck oder Portfolios versuchen Sie 80-90%. Für maximale Komprimierung (Thumbnails, E-Mail) funktionieren 30-50% gut.

Weitere häufig gestellte Fragen

Warum ist meine PNG-Ausgabe nur ein wenig kleiner als das Original?

PNG ist verlustfrei. Die Einsparung kommt vollständig daraus, eine engere DEFLATE-Kompression derselben Pixeldaten zu finden, was typischerweise 5 bis 25 % gegenüber dem spart, was ein Authoring-Werkzeug (Photoshop, Sketch, Figma) standardmäßig geschrieben hat. Wenn Ihre PNG bereits gut optimiert war, bleibt nicht viel Spielraum. Für signifikante zusätzliche Reduktion entweder zu WebP konvertieren (das Transparenz behält und typischerweise 25 % kleiner als PNG ist) oder einen gewissen Verlust akzeptieren, indem zu JPEG konvertiert wird (das viel kleiner sein kann, aber Transparenz fallen lässt).

Funktioniert dieses Werkzeug offline?

Nach dem ersten Besuch ja. Die Bibliothek browser-image-compression (etwa 95 KB minifiziert) wird beim ersten Laden vom Browser zwischengespeichert. Weitere Besuche des Kompressors funktionieren vollständig offline, solange der Browser-Cache zwischendurch nicht geleert wurde. Sie können das verifizieren, indem Sie nach dem einmaligen Öffnen der Seite den Flugmodus aktivieren und ein lokales Bild komprimieren.

Bleiben meine EXIF-Daten (Kamera, GPS, Aufnahmedatum) erhalten?

Nein, EXIF-Metadaten werden bei der Kompression standardmäßig entfernt. Für Web-Sharing ist das meist erwünscht (GPS-Koordinaten und Kamera-Seriennummern sollten nicht durchsickern), aber für Fotografen, die mit intakten Metadaten archivieren, ist dieses Werkzeug nicht das richtige. Verwenden Sie einen EXIF-bewussten Desktop-Kompressor wie ImageOptim (macOS) oder jpegtran mit der Option `-copy all`, um Metadaten zu erhalten.

Was ist der Unterschied zwischen der Maximalbreiten-Verkleinerung und der Qualitätsreduktion?

Verkleinern ändert die Pixelmaße des Bildes: Ein 4000x3000-Foto, auf 1920x1440 verkleinert, hat 75 % weniger Pixel zu codieren, was die Dateigröße schon vor jeder Kompression senkt. Die Qualitätsreduktion (der Schieber) steuert, wie aggressiv der JPEG- oder WebP-Encoder seine DCT-Koeffizienten rundet, was die codierten Daten pro Pixel kleiner macht. Beide addieren sich: erst verkleinern, um die Gesamt-Pixelzahl zu senken, dann die Qualität dessen reduzieren, was übrig bleibt. Für einen typischen «mach das webtauglich»-Workflow Maximalbreite 1920, Qualität 70 einstellen, und die Ausgabe liegt bei etwa 10-15 % der ursprünglichen Größe.

Kann ich HEIC-Bilder von meinem iPhone komprimieren?

Die Browserunterstützung für HEIC-Decodierung ist begrenzt (Safari auf Apple-Geräten kann es; Chrome und Firefox nicht). Auf Nicht-Apple-Browsern lehnt dieses Werkzeug HEIC-Dateien ab. Der Workflow für iPhone-Fotos ist entweder, die iPhone-Einstellung zu ändern (Kamera → Formate → Maximal kompatibel), damit JPEG direkt gespeichert wird, oder HEIC einmal auf einem Mac oder mit einem dedizierten Werkzeug zu JPEG zu konvertieren und diese JPEGs dann durch diesen Kompressor zu schicken. Das «Teilen über»-Blatt von iCloud konvertiert beim Teilen an Nicht-Apple-Empfänger normalerweise automatisch zu JPEG.

Gibt es ein Desktop- oder Kommandozeilen-Äquivalent?

Mehrere. Für die Stapelautomatisierung ist sharp in Node.js die kanonische serverseitige Bibliothek und liefert eine fast identische Ausgabe. ImageMagick (magick input.jpg -quality 70 output.jpg) und GraphicsMagick bewältigen riesige Dateien und laufen von jeder Shell. jpegoptim und optipng sind spezialisierte JPEG- und PNG-Neucodierer, die gegenüber generischen Werkzeugen oft noch ein paar Prozent zusätzlich herausholen. Für einmalige interaktive Arbeit wie dieses Werkzeug, aber mit mehr Reglern, unterstützt Squoosh (Google Chrome Labs, ebenfalls vollständig clientseitig) eine breitere Palette an Formaten, einschließlich AVIF.

Verwandte Werkzeuge