Bilder komprimieren & Fotos verkleinern

Bilder komprimieren & Fotos verkleinern

Bilder online ohne Qualitätsverlust komprimieren. JPG-, PNG- und WebP-Dateien direkt im Browser verkleinern – ohne Server-Uploads, mit Ziel-KB-Solver und ZIP-Batch-Export.

Voreinstellungen:
Komprimierungsmodus

Fotos hierher ziehen oder klicken zum Auswählen

Unterstützt JPG, PNG, WebP, AVIF, GIF, SVG, BMP. Null Serverübertragung.

240 KB
Maximale Abmessungen
B:
H:
Client-seitige PipelineOffscreenCanvas / O(N)
DECRESDCTBINZIP
0.980
SSIM-BildtreuePerzeptuell verlustfrei
Größenreduktion:-0.0%
0 B0 B
Lupen-Vergrößerung:
Trennleiste: 50%

Keine Bilder in der Warteschlange. Ziehen Sie Fotos hierher, um die Stapelverarbeitung zu starten.

Originalgröße0 B
Komprimierte Größe0 B
Eingespart0 B
Kompressionsrate0.0%
Technische Referenz & Architektur-Leitfaden

Bilder komprimieren & Fotos verkleinern — Referenzhandbuch

Bilder online ohne Qualitätsverlust komprimieren. Reduzieren Sie JPG-, PNG- und WebP-Dateigrößen direkt im Browser: ohne Server-Upload, mit exaktem KB-Zielgrößen-Finder und ZIP-Stapelexport.

Bilder komprimieren & Fotos verkleinern — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss
Bilder komprimieren & Fotos verkleinern — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss

Wichtige Parameter & Einstellungen

QuelldateienFileList | Drag-and-Drop-Puffer

Rohbild-Byte-Puffer, die lokal über createImageBitmap und FileReader im isolierten Thread-Speicher des Browsers ohne Netzwerk-Socket-Übertragung dekodiert werden.

Standard: Einzel- oder Mehrfachauswahl
Komprimierungsmodus"quality" | "targetSize"

Algorithmische Ausführungsstrategie zwischen manueller skalarer Quantisierung und einem automatisierten O(log k) Binärsuch-Verfahren zur Einhaltung strikter Byte-Limits.

Standard: quality
Ausgabeformat"image/webp" | "image/jpeg" | "image/png"

Ziel-MIME-Container zur Festlegung von DCT-Quantisierungstabellen, VP8-Intra-Frame-Blockvorhersagen oder RFC 1951 DEFLATE 2D-Filterroutinen.

Standard: image/webp
QualitätsfaktorFloat-Bereich [0,01; 1,00]

Verlustbehaftete Quantisierungsskala für HTMLCanvasElement.toBlob(). Werte unter 0,70 bergen das Risiko hochfrequenter DCT-Ringing-Artefakte, während 0,80 einen SSIM-Index > 0,95 gewährleistet.

Standard: 0.80
Zielgrößen-ObergrenzeGanzzahl (Kilobytes, KB)

Maximaler Dateigrößen-Schwellenwert (z. B. 200 KB für EU-Schengen-Visa, 240 KB für US DS-160 oder biometrische Passfotos), durchgesetzt durch die inverse Nullstellen-Konvergenzschleife.

Standard: 200
Maximale AbmessungenPixel-Bounding-Box (Breite x Höhe)

Maximale räumliche Auflösung via gestuftem bikubischem Resampling, um Pixeloperationen von O(B × H) zu deckeln und WebKit-Canvas-OOM-Abstürze zu verhindern.

Standard: 1920 x 1080 px
FarbquantisierungPalettentiefe (256 | 128 | 64 Farben | Vollfarben)

Farbreduktionsmatrix für PNG-Assets unter Einsatz von Octree-Raumaufteilung und Floyd-Steinberg-Dithering zur Erhaltung von Alpha-Transparenz innerhalb 8-Bit-indizierter Grenzen.

Standard: Vollfarben (24-Bit)
EXIF-Bereinigung"strip" | "safe" | "retain"

Datenschutz-Schutzwall zur Bereinigung von TIFF/EXIF-Segmenten (GPS-Koordinaten, Kamera-Seriennummern, Zeitstempel) während der Re-Serialisierung des Canvas-Rasters.

Standard: strip

Profi-Tipps & Best Practices

Effizienz-Benchmark: WebP versus JPEG

Die Konvertierung fotografischer Bilddaten von Standard-JPEG nach WebP reduziert das Datenvolumen bei identischem Strukturähnlichkeitsindex (SSIM > 0,95) um 25 % bis 35 %. WebP nutzt VP8-Intra-Frame-Makroblock-Vorhersagen und diskrete arithmetische Kodierung, was störende hochfrequente DCT-Ringing-Artefakte an kontrastreichen Kanten wirksam eliminiert.

Canvas-Speicherlimits in mobilem WebKit umgehen

iOS Safari setzt ein striktes Canvas-Speicherlimit (typischerweise 256 MB bis 384 MB kumulativer GPU-Speicher). Führen Sie bei hochauflösenden Smartphone-Fotos (>12 MP) ein gestuftes Downsampling mittels OffscreenCanvas oder createImageBitmap durch und setzen Sie nach der Kompression explizit canvas.width = canvas.height = 0, um die sofortige Garbage Collection des Hardware-Kontexts zu erzwingen.

Binäre Suchkonvergenz für strikte Pass- und Visa-Vorgaben

Behördenportale und Konsulate verlangen strikte Dateigrößen-Obergrenzen (z. B. 200 KB für EU-Schengen-Visa, 240 KB für US DS-160 oder biometrische Passfotos). Der Zielgrößen-Modus führt eine automatisierte 7-stufige Binärsuche über die JPEG/WebP-Quantisierungsparameter aus und konvergiert in unter 300 ms ohne manuelles Ausprobieren zur maximalen wahrnehmbaren Bildqualität.

Octree-Palettenquantisierung für UI-Assets mit Alpha-Kanal

Bei UI-Icons, Logos und Screenshots mit homogenen Farbflächen und Transparenzen zerstört JPEG den Alpha-Kanal, während verlustbehaftetes WebP Halos an Kanten erzeugen kann. Eine 8-Bit-Octree-Palettenquantisierung mit Floyd-Steinberg-Dithering für PNG-Dateien reduziert die Dateigröße um 60 % bis 75 % bei gleichzeitig pixelscharfen Kanten.

Häufige Fehlerquellen & Fehlerbehebung

⚠️Komprimierte Datei ist größer als das Originalbild

Wird ein bereits vorkomprimiertes JPEG oder WebP mit hoher Qualität (≥85 %) neu kodiert, interpretiert der Transformations-Encoder das vorhandene Quantisierungsrauschen und Blockartefakte als echte hochfrequente Bilddetails, was die Entropietabelle aufbläht. Reduzieren Sie die Qualität auf 75 % oder skalieren Sie die Bildabmessungen um 10 % herunter, um den Frequenzbereich effizient neu zu quantisieren.

⚠️Transparenter Hintergrund wird nach der Komprimierung schwarz oder weiß

Der JPEG-Standard (ISO/IEC 10918-1 / JFIF) unterstützt keinen Alpha-Kanal für Transparenz und bettet durchsichtige Pixel auf einem deckenden Hintergrund ein. Wechseln Sie das Ausgabeformat auf WebP (das verlustbehaftete Kompression mit 8-Bit-Alpha-Kanal unterstützt) oder farbquantisiertes 8-Bit-PNG.

⚠️Zielgrößen-Berechner erreicht extrem niedrige KB-Grenze nicht

Bei extrem aggressiven Obergrenzen (z. B. <50 KB bei einem 4K-Bild) erreicht die Quantisierung die minimale Qualitätsuntergrenze (1 %), an der DCT-Header-Tabellen und Lauflängenkodierung keine weiteren Bytes einsparen können. Aktivieren Sie die maximale Auflösungsskalierung, um die Pixelanzahl proportional zu verringern, da das Datenvolumen quadratisch mit den linearen Kantenlängen skaliert.

⚠️Mobiler Browser stürzt ab oder lädt den Tab bei Stapelverarbeitung neu

Die gleichzeitige Dekodierung mehrerer hochauflösender Fotos übersteigt das VRAM-Limit mobiler Browser und führt zum Absturz des Tabs. Reduzieren Sie die Parallelität in den Einstellungen auf 1 (sequenzielle Abarbeitung), damit jeder Bildspeicherpuffer vor der Initialisierung des nächsten Dekodierungskontexts freigegeben und bereinigt wird.

Häufig gestellte Fragen (FAQ)

Wie berechnet der Zielgrößen-Algorithmus exakte KB-Grenzwerte?▼

Die Zielgrößen-Kompression führt eine binäre Suche mit Komplexität O(log k) im Parameterraum der diskreten Kosinustransformation (DCT) zwischen [1, 100] aus. In jeder Iteration prüft der Canvas-Encoder canvas.toBlob() gegen das Byte-Limit: Überschreitet das Ergebnis die Zielgröße, wird der obere Bereich halbiert. So konvergiert das Verfahren innerhalb von maximal 7 Schritten in unter 300 ms zur bestmöglichen Bildqualität.

Welche Bildqualität und Dateigröße sind optimal für Web-Performance?▼

Als optimaler Standard für moderne Webseiten gilt eine WebP-Qualität von 75 % bis 82 %. Dies gewährleistet einen Strukturähnlichkeitsindex (SSIM) von über 0,96, während Hero-Bilder unter 150 KB und Thumbnails unter 70 KB gehalten werden. Damit werden die Kriterien der Google Core Web Vitals für den Largest Contentful Paint (LCP < 2,5 s) sicher erfüllt, ohne sichtbare Kompressionsartefakte zu erzeugen.

WebP vs. JPEG vs. PNG: Welches Format liefert die kleinste Dateigröße?▼

WebP liefert dank VP8-Intra-Frame-Makroblock-Vorhersage bei gleicher visueller SSIM-Präzision um 25 % bis 35 % kleinere Dateien als Standard-JPEG und schrumpft 24-Bit-PNGs mit verlustbehaftetem Alpha-Kanal um über 70 %. PNG bleibt primär für verlustfreie Vektordiagramme, technische Zeichnungen oder 8-Bit-Paletten unverzichtbar, bei denen randscharfer Text frei von DCT-Quantisierungsrauschen bleiben muss.

Warum vergrößert erneutes Komprimieren eines Bildes oft die Datei?▼

Verlustbehaftete Transformationskodierung ist nicht idempotent: Bei einer erneuten Komprimierung mit hoher Qualität (≥85 %) passen die 8x8-DCT-Blockgrenzen oft nicht exakt zum Ursprungsraster. Der Entropie-Encoder erfasst frühere Kompressionsartefakte als reale hochfrequente Bilddetails, was die Huffman- oder arithmetischen Kodierungstabellen aufbläht und die Datei ohne drastische Neuquantisierung um 10 % bis 25 % vergrößert.

Wie schützt die clientseitige Ausführung im Browser vertrauliche Bilddaten?▼

Sämtliche Dekodierungs-, Resampling- und Enkodierungsvorgänge laufen ausschließlich im lokalen Arbeitsspeicher über HTML5 Canvas, createImageBitmap und Web Workers ab – ohne ausgehende HTTP-Anfragen. Die kryptografische Integrität kann über die Web Crypto API (crypto.subtle.digest) innerhalb der lokalen Origin-Sandbox verifiziert werden. Dies garantiert vollständige Konformität mit DSGVO (GDPR), BSI-Richtlinien und der Sicherheitsarchitektur nach RFC 6454.

Warum werden transparente Bildhintergründe bei der JPG-Konvertierung schwarz oder weiß?▼

Die JPEG-Spezifikation (JFIF / ISO/IEC 10918-1) besitzt keinen Alpha-Kanal und kodiert lediglich YCbCr-Helligkeits- und Farbdifferenz-Ebenen. Beim Exportieren von RGBA-Canvas-Puffern nach image/jpeg überblendet der Browser transparente Pixel automatisch mit einem deckenden Hintergrund (in der Regel 0x000000 Schwarz oder 0xFFFFFF Weiß). Um Transparenzen zu bewahren, muss WebP oder PNG gewählt werden.

Verwandte Tools & Hilfsprogramme

Alle Tools →