Bei Komprimierungstools ist die häufigste Marketing-Aussage eine nicht überprüfbare Zahl wie „Volumen um 70 % reduziert“. Dieser Artikel zitiert keine Branchenstatistik, sondern liefert eine Reihe echter Testergebnisse samt vollständiger Vergleichsmethode, die jeder selbst reproduzieren kann.
1. Testgegenstand: Keine Originalbilder, sondern bereits einmal komprimierte Bilder
Die meisten Komprimierungstests verwenden unbearbeitete Kamerabilder – das sind zu ideale Bedingungen. Dieser Test orientiert sich bewusst an einem realen Geschäftsszenario: Eine Website, die Nutzern das Hochladen von Bildern erlaubt, hat beim Import bereits eine eigene, herkömmliche Komprimierung durchgeführt – das Testobjekt besteht also nicht aus unbearbeiteten Rohbildern, sondern aus fertigen Bildern, die bereits „einmal komprimiert“ wurden.
Stichprobenumfang: 78 Ordner mit insgesamt 4624 Bildern (hauptsächlich JPG). Die Verzeichnisstruktur folgt der typischen Archivierung „ein Album pro Ordner“; es wurde weder gefiltert noch bereinigt.
Gesamtgröße dieser Dateien auf dem Server: 1,41 GB.
Die Kernfrage lautet: Wie viel Speicherplatz lässt sich aus einem Bild, das bereits von einem Komprimierungstool verarbeitet wurde, mit einem weiteren Tool noch herausholen? Die meisten Nutzer gehen intuitiv davon aus: „Einmal komprimiert, ist komprimiert – eine erneute Komprimierung bringt kaum etwas.“
2. Kontrollgruppe: Wie viel spart das Verpacken in eine ZIP-Datei?
Bevor ImgZilla läuft, wird dieselbe Dateigruppe unverändert in ein ZIP-Archiv verpackt, um die Wirkung allgemeiner Komprimierungsalgorithmen zu prüfen:
| Größe | relativ zum Original | |
|---|---|---|
| Von der Website komprimierte Originaldatei | 1,41 GB | — |
| Als ZIP gepackt | 1,41 GB | -0,2 % |
Fast keine Veränderung. Der Grund ist nicht kompliziert: JPEG ist selbst ein komprimiertes Format. Die Bilddaten wurden bereits einer Entropiecodierung unterzogen; allgemeine Algorithmen (ZIP verwendet DEFLATE) können bei bereits komprimierten Daten kaum noch etwas einsparen – unabhängig davon, ob die Originalbilder von der Website verarbeitet wurden oder nicht. ZIP kann daran nichts ändern.
3. ImgZilla-Nachkompression im Praxistest
Die oben genannten Dateien werden in ImgZilla gezogen und direkt an Ort und Stelle komprimiert. 78 Ordner, 4624 Bilder, Dateinamen und Verzeichnisstruktur bleiben vollständig erhalten:
| Größe | relativ zum Original | |
|---|---|---|
| Von der Website komprimierte Originaldatei | 1,41 GB | — |
| Als ZIP gepackt | 1,41 GB | -0,2 % |
| Nach ImgZilla-Neukomprimierung | 0,75 GB | -46,8 % |
Ausgehend von der bereits von der Website durchgeführten Komprimierung spart ImgZilla zusätzlich rund 662 MB – die Dateigröße wird fast halbiert. Alle Ordnerpfade, Dateinamen und Ebenen bleiben unverändert – das sind direkt überprüfbare echte Daten, keine Marketing-Sprüche.
Dies zeigt einen entscheidenden Punkt: „Beim Hochladen von der Website komprimiert“ und „fein codierte Komprimierung mit formatspezifischen Parametern“ sind zwei verschiedene Dinge. Die meisten Websites führen beim Import eine einmalige, eher konservative Komprimierung durch (meist nur Begrenzung der Qualitätsparameter oder Abmessungen), die bei Weitem nicht den gesamten Codierungsspielraum jedes Formats ausschöpft. ImgZilla stimmt die Parameter für jedes Format individuell ab und führt bei JPEG eine visuell verlustfreie Neucodierung durch – auf Pixelebene gibt es zwar Veränderungen, aber die Parameter liegen in einem Bereich, der mit bloßem Auge praktisch nicht zu unterscheiden ist. So wird auch aus „bereits komprimierten“ Daten noch weiter Speicherplatz herausgeholt.
Hier muss ein häufig verwechseltes Konzept klargestellt werden: „Visuell verlustfrei“ ist nicht dasselbe wie „verlustfrei“. Echte Verlustfreiheit (Pixel völlig unverändert) gilt nur für PNG (oxipng) und SVG; JPEG, WebP, AVIF, HEIC und GIF sind grundsätzlich verlustbehaftete Neucodierungen, nur dass die Komprimierungsparameter so eingestellt sind, dass sie unterhalb der Wahrnehmbarkeitsschwelle des Auges bleiben. ImgZilla verfügt über ein eingebautes Vergleichsfenster, mit dem man die Bilder vor und nach der Komprimierung nebeneinander vergleichen und auf Originalgröße zoomen kann – zur pixelgenauen Überprüfung.
4. Detaillierte Analyse: Kompressionsraten pro Datei, Pixelmaße und Bearbeitungszeit
Die zuvor genannten 46,8 % Gesamtkomprimierung sind das Ergebnis aller 4624 Bilder. Betrachtet man einzelne Dateien, ergeben sich weitere Details.
Die Kompressionsraten sind ungleichmäßig verteilt
Berechnet man für jedes Bild die Kompressionsrate (komprimierte Bytes / ursprüngliche Bytes), so reicht die Spanne von 32,3 % bis 85,8 %:
- Die höchste Kompressionsrate: ca. 765 KB werden auf 109 KB reduziert, also eine Kompressionsrate von 85,8 % – solche Bilder sind in der Regel anfänglich nur schwach komprimiert und bieten noch viel Raum für eine Neucodierung.
- Die niedrigste Kompressionsrate: ca. 572 KB werden auf 387 KB reduziert, also eine Kompressionsrate von 32,3 % – solche Bilder wurden bereits stärker komprimiert und bieten nur begrenztes Potenzial.
- Der arithmetische Mittelwert der Kompressionsraten aller 4624 Bilder liegt bei 46,44 %, nahe an den 46,8 %, berechnet aus dem Gesamtvolumen, aber nicht exakt identisch – Ersteres ist der einfache Durchschnitt der einzelnen Kompressionsraten, Letzteres ist „gesparte Gesamtbytes ÷ ursprüngliche Gesamtbytes“. Der Unterschied zeigt, dass Dateien mit hohen und niedrigen Kompressionsraten im Gesamtvolumen nicht symmetrisch gewichtet sind; wenige große Dateien haben einen größeren Einfluss auf die Gesamtsumme.
Bemerkenswert ist: Alle Kompressionsraten sind positiv; kein einziges Bild wurde als „bereits minimal, übersprungen“ markiert – d. h., jedes dieser von der Website bereits komprimierten Bilder kann von ImgZilla noch weiter tatsächlich verkleinert werden.
Pixelmaße: kein einziger Unterschied
Bei einer statistischen Auswertung der Pixelmaße aller 4624 Bilder ist das häufigste Format 1600×2400 (1756 Bilder) und dessen Querformat 2400×1600 (500 Bilder). Die Größen reichen von 450×675 (ca. 300.000 Pixel) bis zu 3000×2000 / 2000×3000 (ca. 6 Millionen Pixel).
Stichprobenartiger Abgleich der Pixelmaße vor und nach der Komprimierung ergibt: vollständig identisch, keine Abweichung:
| Datei (Beispiel) | Originalmaß | Maß nach Komprimierung |
|---|---|---|
| Probe 1 | 1600×1066 | 1600×1066 |
| Probe 2 | 2000×3000 | 2000×3000 |
| Probe 3 | 1416×2128 | 1416×2128 |
Das ist die andere, oft übersehene Hälfte des Begriffs „Komprimierung vor Ort“: Es bleiben nicht nur Dateiname und Pfad erhalten, sondern auch die Auflösung wird absolut nicht verändert. ImgZilla skaliert nicht und beschneidet nicht – die gesamte Volumenreduktion stammt aus der Neucodierung, nicht aus dem Opfern von Pixeln.
Bearbeitungsdauer: 4624 Bilder in 51 Minuten 32 Sekunden, durchschnittlich 0,669 Sekunden pro Bild
Testumgebung: Mac mini mit Apple-M1-Chip, 8 GB einheitlicher Speicher, Bilddateien auf einer NAS-Festplatte, verbunden über ein 2,5G-Kabelnetzwerk.
Anhand der letzten Schreibzeit jeder Datei (dem Zeitpunkt, zu dem ImgZilla die Komprimierung abgeschlossen und die Datei zurückgeschrieben hat) lässt sich der Fortschritt verfolgen: Die erste Datei wurde um 16:06:09 geschrieben, die letzte um 16:57:41. Die Gesamtbearbeitung dauerte 51 Minuten und 32 Sekunden, also durchschnittlich 0,669 Sekunden pro Bild.
Diese Zahl passt zur „seriellen Verarbeitung“ des Produkts – die Bilder werden nacheinander komprimiert, nicht parallel in zufälliger Reihenfolge geschrieben. Umgerechnet sind das etwa 90 Bilder pro Minute. Die tatsächliche Geschwindigkeit hängt von Bildgröße und Maschinenleistung ab; hier handelt es sich lediglich um die real gemessene Dauer für diese Stichprobe mit durchschnittlich ca. 305 KB pro Bild in der genannten Umgebung – kein allgemeingültiger Benchmark.
5. Warum „vor Ort“ komprimieren statt eine Kopie zu speichern?
Wenn dieser Test mit einem Tool durchgeführt worden wäre, das „komprimierte Versionen“ speichert, wäre das Ergebnis: Originaldatei 1,41 GB + komprimierte Version 0,75 GB, zusammen 2,16 GB – also sogar mehr Platzverbrauch. Außerdem würden viele xxx-min.jpg-Dateien entstehen, die manuell aufgeräumt und deren Referenzen in Datenbank oder Produkttabellen aktualisiert werden müssten.
ImgZilla überschreibt die Dateien direkt: Das Komprimierungsergebnis wird an den ursprünglichen Pfad zurückgeschrieben, alle 4624 Dateinamen in den 78 Ordnern bleiben unverändert – das ist besonders wichtig für Websites, die Bildpfade bereits in Datenbanken, CDNs oder CMS-Referenzen eingetragen haben; nach der Komprimierung muss kein einziger Link angepasst werden. Der Preis dafür: Die Originaldatei wird verändert. Daher verschiebt ImgZilla das Originalbild standardmäßig zunächst in den System-Papierkorb, bevor das komprimierte Ergebnis geschrieben wird. Falls man es sich anders überlegt, kann man es im Papierkorb per Rechtsklick „Zurücklegen“ wiederherstellen.
6. Nutzenanalyse: Vom realen Szenario zur monatlichen Rechnung
Für wen diese Daten praktisch relevant sind
- Websites/Entwickler mit nutzergenerierten Bild-Uploads: Bildspeicher und CDN-Traffic werden in der Regel pro GB abgerechnet. Eine Halbierung des Volumens bedeutet eine direkte Halbierung der Rechnung – wobei die Traffic-Gebühr bei jedem Zugriff anfällt. Je größer die Zugriffszahl, desto stärker der Zinseszinseffekt. Selbst wenn bereits beim Import eine herkömmliche Komprimierung stattfindet, zeigt dieser Test, dass eine weitere, speziell abgestimmte Komprimierung immer noch beachtliche Vorteile bringt.
- Server mit knappem Speicherplatz / Nutzer kleiner Datenträger: Bereinigungstools löschen üblicherweise Cache und Duplikate, aber nach einigen Monaten füllt sich der Speicher wieder; der durch Komprimierung gewonnene Platz hingegen entsteht dadurch, dass vorhandene Dateien selbst kleiner werden – er wächst nicht wieder nach. Bei diesen 78 Ordnern wurden durch die Komprimierung direkt 662 MB zusätzlich verfügbar, und zwar dauerhaft freigegeben.
- Nutzer, die häufig Daten übertragen: Beim Kopieren, Synchronisieren und Backup verkürzt sich die Übertragungszeit dank 46,8 % Volumenreduzierung nahezu proportional. Einmal komprimiert, spart man bei jedem späteren Transfer Zeit.
Umrechnung in monatliche Kosten: Wie viel ist diese 46,8 % wert?
Eine Volumenreduktion muss sich letztlich in der Rechnung niederschlagen, um zu überzeugen. Im Folgenden werden keine Statistiken wie „Komprimierung steigert die Conversion-Rate“ zitiert, sondern lediglich die in diesem Test gemessenen 46,8 % mit den öffentlich zugänglichen Speicher-/Traffic-Preisen großer Cloud-Anbieter multipliziert – eine rein arithmetische Abschätzung.
Einsparung bei den Speicherkosten = eingespartes Volumen (GB) × Einzelpreis (Yuan oder Dollar / GB / Monat)
Einsparung bei den ausgehenden Traffic-Kosten = eingespartes Volumen (GB) × Anzahl der Downloads/Zugriffe im Monat × Einzelpreis (Yuan oder Dollar / GB)
Wenn das Volumen halbiert wird, werden auch diese beiden Rechnungspositionen ungefähr halbiert – das ist Mathematik, keine Spekulation.
Speicherkosten: Je größer die Bilddatenbank, desto deutlicher der Gewinn
Anbieter aus China (Yuan-Preise):
| Ursprüngliche Bilddatenbank | Eingespartes Volumen | Alibaba Cloud OSS Standard-Storage ¥0,09/GB/Monat |
|---|---|---|
| 10 GB | 4,68 GB | ¥0,42/Monat |
| 100 GB | 46,8 GB | ¥4,21/Monat |
| 1 TB | 479 GB | ¥43,1/Monat |
Internationale Anbieter:
| Ursprüngliche Bilddatenbank | Eingespartes Volumen | AWS S3 Standard $0,023/GB/Monat |
Google Cloud Storage $0,020/GB/Monat (Regional, USA) |
Azure Blob Storage $0,018/GB/Monat (Hot, LRS) |
Cloudflare R2 $0,015/GB/Monat |
|---|---|---|---|---|---|
| 10 GB | 4,68 GB | $0,11/Monat | $0,09/Monat | $0,08/Monat | $0,07/Monat |
| 100 GB | 46,8 GB | $1,08/Monat | $0,94/Monat | $0,84/Monat | $0,70/Monat |
| 1 TB | 479 GB | $11,02/Monat | $9,58/Monat | $8,62/Monat | $7,19/Monat |
Die Speicherpreise der internationalen Anbieter liegen sehr eng beieinander (Unterschiede unter 30 %). Entscheidend ist nicht, wer billiger ist, sondern: Ganz gleich, für welchen Anbieter man sich entscheidet – halbiert sich das Volumen, halbiert sich auch dieser Rechnungsposten nahezu, und das monatlich wiederkehrend. Einmal komprimiert, wird ab dann jeden Monat nach dem neuen Volumen abgerechnet. Es handelt sich also um eine einmalige Investition mit langfristig wiederkehrendem Nutzen.
Traffic-Kosten: Der eigentliche Posten, der mit den Zugriffen wächst
Traffic-Kosten sind wichtiger als Speicherkosten, denn sie sind ein Produkt aus Volumen × Anzahl der Downloads. Je häufiger Bilder abgerufen werden, desto größer der Komprimierungsgewinn. Angenommen, eine 100-GB-Bilddatenbank erzeugt im Monat 500 GB ausgehenden Traffic über CDN (entspricht etwa fünf vollständigen Downloads der Datenbank):
| CDN-/Ausgangstraffic-Preis (erste Preisstufe) | Monatliche Traffic-Kosten vor der Komprimierung | Nach der Komprimierung (Traffic sinkt um 46,8 %) | Ersparnis pro Monat | Ersparnis pro Jahr |
|---|---|---|---|---|
| Alibaba Cloud CDN Inland (untere Stufe ¥0,15/GB) | ¥75,0 | ¥39,9 | ¥35,1 | ¥421 |
| AWS CloudFront Asien-Pazifik ($0,12/GB) | $60,0 | $31,9 | $28,1 | $337 |
| Google Cloud CDN Nordamerika/Europa ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
| Azure Front Door Standard Zone 1 ($0,08/GB) | $40,0 | $21,3 | $18,7 | $224 |
Hier wurde jeweils die niedrigste Preisstufe angenommen. In der Praxis sind die gestaffelten Preise oft höher (beim Alibaba Cloud CDN kann die Inlandsstufe bis zu ¥1,31/GB erreichen). Je höher die Rechnung, desto größer der absolute Einspareffekt durch Komprimierung. Zudem enthält die Azure-Stufe derzeit Azure Front Door Standard, das neben dem pro GB abgerechneten ausgehenden Traffic eine Grundgebühr von ca. $35/Monat beinhaltet; diese Gebühr kann durch Komprimierung nicht reduziert werden und ist in den Ersparnissen der Tabelle nicht enthalten.
Cloudflare R2 ist eine Ausnahme: Deren ausgehender Traffic kostet grundsätzlich $0 – wenn der Speicher-Bucket mit R2 kombiniert wird, schlägt sich der Komprimierungsgewinn fast vollständig in den Speicherkosten nieder; für den Traffic gibt es ohnehin keine Rechnung. Dies unterscheidet sich von der doppelten Abrechnungsstruktur „Speicher + Traffic“ (z. B. Alibaba Cloud OSS+CDN, AWS S3+CloudFront). Bevor man sich für einen Anbieter entscheidet, sollte man seine eigenen Abrechnungspositionen kennen.
Bei den oben genannten Preisen handelt es sich um öffentlich zugängliche Listenpreise der Plattformen aus dem Jahr 2026. Tatsächliche Preise können je nach Region, Rabatten und Preisstufen abweichen; maßgeblich sind die aktuellen Preise auf der Website. Die Download-Zahlen und Zugriffsvolumina sind Beispielannahmen; bitte ersetzen Sie sie durch die echten Werte aus Ihrer Rechnung.
7. Zeitersparnis bei Übertragung und Upload
Halbiert sich das Volumen, verkürzt sich die Übertragungszeit nahezu proportional – das gilt unabhängig von Cloud-Rechnungen, sowohl für lokale Kopien und Backups als auch für den Upload durch Nutzer.
Lokale Szenarien: USB 3 und Gigabit-Netzwerk
- USB-3-Mobilfestplatte: Typischer Durchsatz 100–150 MB/s, hier wird der Medianwert 120 MB/s angenommen.
- USB-3-Mobil-SSD: Deutlich höherer Durchsatz, üblich sind 400–500 MB/s, angenommen werden 450 MB/s.
- Gigabit-Kabelnetzwerk (1000 Mbps): Theoretisches Limit 125 MB/s, nach Abzug des Protokoll-Overheads real etwa 100–110 MB/s, angenommen werden 105 MB/s.
Die oben genannten Werte sind Schätzungen aus typischen Messbereichen; die tatsächliche Geschwindigkeit hängt von Datenträger, Schnittstellenqualität und Netzwerkumgebung ab und dient nur zur groben Orientierung.
| Szenario | Eingespartes Volumen | USB-3-HDD @120 MB/s | USB-3-SSD @450 MB/s | Gigabit-Netzwerk @105 MB/s |
|---|---|---|---|---|
| Die in diesem Test verwendeten Bilder | 662 MB | ≈5,5 Sekunden | ≈1,5 Sekunden | ≈6,3 Sekunden |
| 10-GB-Bilddatenbank | 4,68 GB | ≈40 Sekunden | ≈10 Sekunden | ≈45 Sekunden |
| 100-GB-Bilddatenbank | 46,8 GB | ≈6,5 Minuten | ≈1,7 Minuten | ≈7,4 Minuten |
| 1-TB-Bilddatenbank | 479 GB | ≈66 Minuten | ≈18 Minuten | ≈76 Minuten |
Die hier gemessenen 662 MB wirken auf den ersten Blick gering – nur wenige Sekunden. Aber genau wie bei den Speicherkosten gilt: Es ist eine einmalige Investition mit langfristigem Nutzen. Ob man Daten auf eine externe Festplatte kopiert, mit der NAS synchronisiert, ein Time-Machine-Backup fährt, auf einen neuen Mac umzieht oder Dateien an Kollegen weitergibt – solange man diese Daten überträgt, spart man bei jedem Mal im gleichen Verhältnis Zeit. Einmal komprimiert, spart jeder weitere Transfer.
Wenn die Komprimierung vor dem Upload durch den Nutzer erfolgt: Gesparte Wartezeit
Bisher wurden die Vorteile nach der Speicherung betrachtet – Speicherkosten, CDN-Traffic, lokale Übertragung. Doch es gibt noch einen weiteren Aspekt, der noch stärker ins Gewicht fällt: die Wartezeit zwischen dem Klick auf „Hochladen“ und dem Ende des Fortschrittsbalkens. Diese nutzt die Upload-Bandbreite des Nutzers – und der Upload ist in der Regel der langsamste Engpass der gesamten Kette. Bei den meisten Breitbandanschlüssen beträgt der Upload nur ein Zehntel bis ein Fünftel des Downloads, besonders im Mobilfunk. Wenn die Website oder App Bilder vor dem Upload mit ImgZilla komprimiert, wird das eingesparte Volumen direkt zu kürzeren Wartezeiten für den Nutzer.
Auf Basis der durchschnittlichen Bildgröße in diesem Test: Die von der Website bereits komprimierten Originalbilder haben durchschnittlich 299 KB, nach der erneuten Komprimierung mit ImgZilla durchschnittlich 159 KB – pro Bild werden also rund 140 KB eingespart.
| Upload-Bandbreite (typische Bereiche aus öffentlichen Speedtest-Daten, nur zur Orientierung) | Einzelnes Bild 299 KB → 159 KB |
Hochladen eines Albums mit 50 Bildern ≈15,0 MB → 8,0 MB |
Hochladen aller 4624 Bilder aus diesem Test 1,41 GB → 0,75 GB |
|---|---|---|---|
| Mobiles Netz (4G/5G kombiniert, inländische Speedtest-Mediane ca. 10–50 Mbps, angenommen 30 Mbps) | ca. 0,04 Sek. gespart | ca. 1,9 Sek. gespart | ca. 3 Minuten gespart |
| Typischer Haushalts-Breitband-Upload (100M-/1000M-Downstream-Tarife, Upload oft begrenzt, ca. 20–30 Mbps, angenommen 25 Mbps) | ca. 0,04 Sek. gespart | ca. 2,2 Sek. gespart | ca. 3,5 Minuten gespart |
| Symmetrisches Gigabit (einige Anbieter/Unternehmensleitungen, 1000 Mbps) | ca. 0,001 Sek. gespart | ca. 0,06 Sek. gespart | ca. 5,3 Sekunden gespart |
| Internationale Referenz: durchschnittlicher US-Breitband-Upload (Ookla-Daten, 2026) | ca. 0,02 Sek. gespart | ca. 1 Sek. gespart | ca. 1,5 Minuten gespart |
Betrachtet man einzelne Bilder, wirkt die Tabelle fast bedeutungslos – 0,04 Sekunden sind praktisch nicht wahrnehmbar. Das ist ein ehrliches Ergebnis: Die Testbilder selbst sind bereits relativ klein (die Website hat sie vor dem Speichern komprimiert, im Schnitt nur 299 KB pro Bild). Der wahre Nutzen zeigt sich in zwei Szenarien: das gleichzeitige Hochladen eines ganzen Albums oder dutzender Bilder in einem Stapel sowie deutlich größere Rohdaten (z. B. JPEGs direkt aus der Kamera oder erstmalig hochgeladene UGC-Inhalte ohne Website-Komprimierung – einzelne Bilder haben dann oft mehrere MB statt einiger hundert KB). Bei gleicher Kompressionsrate wächst die absolut eingesparte Sekundenzahl proportional. Für mobile Nutzer mit ohnehin langsamer Upload-Bandbreite ist die Verkürzung der Wartezeit noch deutlicher spürbar.
Die Zahlen für Mobilnetz und Haushalts-Breitband basieren auf öffentlichen inländischen Speedtest-Statistiken (4G/5G-Mediane, übliche Upload-Verhältnisse bei Breitband); die tatsächlichen Geschwindigkeiten hängen stark von Anbieter, Region, Gerät und Netzlast ab und sind nur als Größenordnung zu verstehen. Der US-Breitband-Upload-Wert stammt aus Ookla-Speedtest-Berichten.
Möchten Sie es selbst überprüfen? Laden Sie ImgZilla direkt aus dem Mac App Store herunter und testen Sie es mit einigen bereits verarbeiteten Bildern von Ihrer eigenen Website, bevor Sie entscheiden, ob Sie weitere komprimieren.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
Mehr erfahren: https://imagetool.app/ImgZilla