Kostenloser Stapel-Bildkonverter

Über die Konvertierung von Bildformaten

Verschiedene Bildformate erfüllen unterschiedliche Zwecke. PNG ist verlustfrei und ideal für Grafiken, JPG eignet sich am besten für Fotos mit kleineren Dateigrößen, und WebP bietet moderne Kompression bei hoher Qualität. Stapelkonvertierung spart Zeit, wenn mehrere Dateien zu verarbeiten sind.

JPEG (1992), das Fotoformat

Die Joint Photographic Experts Group wurde im November 1986 in Parsippany, New Jersey gegründet, mit Mitgliedern aus ISO TC97 SC2/WG8 und der CCITT-SGVIII-Gruppe. Sechs Jahre Komiteearbeit später wurde der Text der CCITT-Empfehlung T.81 am 18. September 1992 verabschiedet, mit demselben Text 1994 als ISO/IEC International Standard 10918-1 veröffentlicht. Diese Doppel-veröffentlichung ist der Moment, in dem JPEG zum Foto-Format der Welt wurde. Der mathematische Kern ist die diskrete Kosinus-Transformation, angewandt auf 8×8-Pixel-Blöcke: Jeder Block wird in eine Summe von Kosinuswellen zerlegt; die hochfrequenten Anteile, für die das menschliche Sehvermögen am wenigsten empfindlich ist, werden aggressiver quantisiert als die niederfrequenten, die das Auge zuerst bemerkt. Der nutzerseitige „Qualitäts“-Regler ist genau das, ein Multiplikator auf der Quantisierungstabelle. Höhere Qualität bedeutet kleinere Divisoren, mehr Präzision, größere Dateien. Niedrigere Qualität bedeutet mehr Nullen nach Quantisierung, bessere Entropiekodierung und eine kleinere Datei auf Kosten sichtbarer Block- und Ringing-Artefakte. JPEG ist von Natur aus verlustbehaftet: Es gibt keine Qualitätseinstellung, bei der ein JPEG-Round-Trip mathematisch identisch zu seiner Eingabe ist. Für Fotografien natürlicher Szenen (Gesichter, Landschaften, Essen, alles mit weichen Verläufen und kontinuierlichem Ton) ist das irrelevant; der Verlust lebt unterhalb der Empfindlichkeitsschwelle des menschlichen Sehens, und die Datei ist ein Bruchteil der Größe, die ein verlustfreies Format produzieren würde. Für Grafiken mit harten Kanten, Text, Strichgrafiken oder großen einfarbigen Flächen ist JPEG die falsche Wahl: Dieselbe DCT verschmiert scharfe Kanten mit Ringing-Artefakten („Mosquito Noise“) und klobigen Grenzen zwischen 8×8-Zellen.

PNG (Oktober 1996 / Januar 1997), das verlustfreie Grafikformat

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15. Juni 1987), der Animations-Überlebende und die Patentsaga

Steve Wilhite, der Engineering-Lead bei CompuServe, stellte GIF am 15. Juni 1987 vor, um ein spezifisches Problem zu lösen: wie man Farbbilder über die langsamen Modems des CompuServe-Onlinedienstes teilen kann, ohne dass die Dateien das monatliche Kontingent des Nutzers verschlingen. Sein Team wählte den Lempel-Ziv-Welch (LZW) Kompressionsalgorithmus und begrenzte die Farbpalette auf 256 Einträge. Was CompuServe 1987 nicht wusste: LZW war 1985 von der Sperry Corporation (später Unisys) patentiert worden. Das Patent-Thema brach Ende 1994 öffentlich aus. Unisys kündigte 1995 an, Lizenzgebühren auf Software, die den Algorithmus verwendete (einschließlich GIF, TIFF und PDF) in Höhe von etwa 0,45 % bis 0,65 % des Umsatzes zu erheben. Die Open-Source-Community des Webs reagierte mit zwei parallelen Aktionen: der „Burn All GIFs“-Kampagne und der Konzeption von PNG, ausdrücklich als patentfreier GIF-Ersatz. Das US-Patent von Unisys lief im Juni 2003 aus; entsprechende Patente in anderen Jurisdiktionen liefen bis 2004 aus. Bis 2004 war GIF zum ersten Mal in seiner Geschichte patentfrei. GIF überlebte wegen einer Funktion, die PNG (ursprünglich) nicht hatte: Animation. Es unterstützt eine Folge von Frames mit Verzögerungs-Timings pro Frame und einem transparenten Paletten-Index, was es zur Lingua franca von Loop-Reaction-Bildern und Web-Bannern macht. Die 256-Farb-Palette ist eine echte Beschränkung für Fotos, und die 1-Bit-Transparenz erzeugt hässliche Ränder bei Überlagerung auf farbigem Hintergrund, aber für kurze Loop-Animationen comicartiger Inhalte gewinnt GIF immer noch durch universelle Unterstützung.

BMP (Mai 1990) und TIFF (Herbst 1986), die Legacy-Holdouts

BMP (Bitmap, auch Windows Device Independent Bitmap genannt) wurde in Windows 3.0 integriert, das am 22. Mai 1990 veröffentlicht wurde, wo es zum Standard für Bitmap-Speicherung in der grafischen Windows-Umgebung wurde. Es ist im Wesentlichen unkomprimiert, das rohe Pixel-Array, optional zeilenweise auf 4-Byte-Grenze ausgerichtet, mit einem kleinen Header vorne. Ein 1920×1080 24-Bit-BMP ist etwa 6,2 MB; dasselbe Bild als JPEG-Qualität-85 könnte 200 KB sein. BMPs Rolle 2026 ist im Wesentlichen die eines Legacy-Austauschformats und das Format, das Windows-Screenshots historisch verwendeten. TIFF (Tagged Image File Format) wurde erstmals von der Aldus Corporation im Herbst 1986 (Revision 3.0) veröffentlicht; Revision 6.0 im Juni 1992 fügte CMYK- und YCbCr-Farben sowie JPEG-in-TIFF hinzu. Adobe übernahm Aldus 1994 und hält jetzt das Copyright. TIFF ist insofern einzigartig, als es ein Container-Format und kein einzelnes Kodierungsschema ist, eine einzelne TIFF-Datei kann mehrere Bilder enthalten (mehrseitiges TIFF, üblich für Fax und gescannte Buchkapitel), beliebige von mehreren Kompressionsmethoden verwenden (keine, LZW, ZIP, JPEG, CCITT Group 3/4 für Fax) und im Grunde beliebige Metadaten über seine getaggte Feldstruktur speichern. Diese Flexibilität macht TIFF zum Standard für Druckvorstufen-Workflows, Scannen und Dokumentarchivierung; es wird im Wesentlichen nie für Webbilder verwendet. Seine Präsenz in der Eingabeliste ist für Nutzer, die druck- oder scangebundene Quellen in webfreundliche Formate konvertieren.

WebP (30. September 2010), das moderne Webformat

Google kündigte WebP am 30. September 2010 als ein neues offenes Format für verlustbehaftet komprimierte True-Color-Grafiken im Web an, das Dateien produziert, die kleiner als JPEG bei vergleichbarer Qualität sind. Das Format basiert auf der Keyframe-Kodierung des VP8-Videocodecs, den Google mit dem Kauf von On2 Technologies erworben hatte. Anfangs war WebP nur verlustbehaftet. Am 18. November 2011 kündigte Google einen verlustfreien Kompressionsmodus und Unter-stützung für Transparenz in beiden Modi an; libwebp 0.2.0 erreichte am 16. August 2012 eine stabile verlustfreie Implementierung. Laut Googles Entwicklerdokumentation: Verlustfreie WebP-Bilder sind etwa 26 % kleiner als dieselben Bilder in PNG, und verlustbehaftete WebP-Bilder sind 25-34 % kleiner als vergleichbare JPEGs bei äquivalenter SSIM-Qualität. Diese Reduktionen sind keine Magie, sie kommen von einem grundsätzlich neueren Codec-Design (prädiktive Intra-Frame-Kodierung, moderne arithmetische Entropiekodierung, intelligentere Farbtransformationen) als die frühen-1990er-Baselines, gegen die JPEG und PNG entworfen wurden. Browser-Unterstützung war ein langsamer Aufbau: Chrome 17 im Februar 2012 (verlustbehaftet), Chrome 23 im November 2012 (verlustfrei). Apple hielt fast ein Jahrzehnt durch und fügte schließlich WebP-Unterstützung in Safari 14 hinzu, das mit iOS 14 und macOS 11 Big Sur im September 2020 ausgeliefert wurde. Dieses September-2020-Datum ist der Moment, an dem WebP praktisch als primäres Webformat ohne JPEG-Fallback für iPhone-Nutzer verwendbar wurde. Die Abdeckung beträgt heute etwa 97 % des globalen Traffics, WebP ist kein „modernes“ Format mit Vorbehalten mehr, es ist ein Default.

Jenseits von WebP: AVIF (Feb 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 wurde am 19. Februar 2019 von der Alliance for Open Media (AOMedia, einem Konsortium aus Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple) veröffentlicht. Es ist das Standbildprofil des AV1-Video-codecs, gebaut auf dem HEIF-Container, und ist derzeit das am besten komprimierende, weit verbreitete Bildformat, bei äquivalenter visueller Qualität sind AVIF-Dateien typischerweise 50 % kleiner als JPEG und 20-30 % kleiner als WebP. Browser-Unterstützung kam in drei Wellen: Chrome 85 (August 2020), Firefox 93 (Oktober 2021), Safari mit iOS 16 (September 2022) und macOS Ventura (Oktober 2022). HEIC ist das iPhone-Default-Format seit iOS 11 in 2017, der HEIF-Container mit HEVC-komprimierten Bildern, formal ISO/IEC 23008-12. Kompression ist exzellent (typischerweise 50 % kleiner als JPEG), aber HEVC ist patentbelastet, weshalb Chrome, Firefox und Nicht-Apple-Edge HEIC nicht nativ decodieren. JPEG XL (ISO/IEC 18181, 2022) ist das technisch exzellente Nischenformat, es kann bestehende JPEGs verlustfrei auf etwa 20 % kleiner rekomprimieren, unterstützt HDR, Wide Gamut, Animation und progressives Decoding und ist patentfrei. Chrome ließ seinen experimentellen Flag am 31. Oktober 2022 fallen (die „Halloween-Entscheidung“); Apple lieferte Safari 17 im September 2023 mit nativem JPEG XL über macOS Sonoma, iOS 17 und visionOS. Das Format wird nativ in Safari 17+ unterstützt, hinter einem Flag in Firefox und Chrome 145 (Februar 2026), aber Auslieferung-by-default für allgemeinen Traffic bleibt ausstehend. Dieser Konverter emittiert AVIF, HEIC oder JPEG XL derzeit nicht, sie sind hier aufgelistet, damit Sie entscheiden können, ob Sie sie upstream behandeln.

Das richtige Ausgabeformat wählen

Die Format-für-Format-Geschichte oben ist eine Tour. Die praktische Frage ist kürzer: gegeben ein bestimmtes Bild und eine bestimmte Verwendung, welches Ausgabeformat ist richtig?

• Fotografien mit weichen Verläufen (Menschen, Essen, Landschaften, Produktaufnahmen): JPEG bleibt die sichere Antwort für maximale Kompatibilität, mit Qualität 75-85. WebP bei derselben visuellen Qualität wird 25-34 % kleiner sein und wird in 97 % der Browser unterstützt.
• Strichgrafiken, Screenshots mit Text, Logos, Diagramme, Illustrationen: PNG ist der Default. Die harten Kanten und großen einfarbigen Flächen, die für diese Bilder charakteristisch sind, sind genau das, was JPEG am schlechtesten handhabt, DCT-Ringing-Artefakte verschmieren die Kanten und lassen Text unscharf aussehen. WebP-lossless ist etwa 26 % kleiner als PNG für denselben Inhalt.
• Web-Optimierung für Blogposts: WebP ist der neue Default für neue Inhalte; kombinieren Sie es mit einem JPEG-Fallback für Legacy-Traffic, falls Ihr Publikum es erfordert.
• Social-Media-Varianten: die meisten Plattformen rekodieren ohnehin, was Sie hochladen, also zählt das Quellformat weniger als die Quellauflösung und -qualität. Eine 4000×4000 PNG auf Instagram hochzuladen spart keine Qualität gegenüber dem Hochladen einer 1080×1080 JPEG-Qualität-90, Instagram resampelt und rekomprimiert beide intern.
• Archivformat-Normalisierung: PNG (verlustfrei) für Grafiken, TIFF für Druckvorstufen- und Scan-Archive, wo der nachgelagerte Workflow TIFF erwartet. Vermeiden Sie WebP und AVIF für die Langzeitarchivierung, beide sind noch jung, und die Decoder-Verfügbarkeit Jahrzehnte ab jetzt kann nicht mit derselben Zuversicht angenommen werden wie bei JPEG und PNG.
• iPhone-Export: HEIC zu JPEG für maximale Kompatibilität, zu WebP für Webnutzung, oder zu AVIF für hochmoderne Sites konvertieren. Die Lizenzkomplikation rund um HEIC ist genau der Grund, warum ein HEIC-zu-irgendetwas-anderem-Konverter nützlich ist.

Was der Qualitätsregler tatsächlich macht

Der Qualitätsregler läuft von 10 bis 100 in 5er-Schritten. Hinter dieser einzelnen Zahl steht eine überraschend nichtlineare Beziehung zwischen wahrgenommener Qualität und Dateigröße. Für JPEG ist der Konsens in der Bildverarbeitungs-Engineering-Community, dass Qualität 75-85 der Sweet Spot ist. Bei Qualität 80 sinkt die Dateigröße um 70-90 % gegenüber einer unkomprimierten Quelle mit imperzeptiblem visuellem Unterschied bei normalen Bildschirm-Betrachtungsabständen. Der Abfall zwischen Qualität 80 und 85 ist steil: ein repräsentatives Testbild könnte von 3,7 MB bei Qualität 80 auf 6 MB bei Qualität 85 gehen, fast eine Verdoppelung ohne sichtbare Verbesserung auf einem Telefon- oder Laptop-Bildschirm. Qualität 75 ist, wo Artefakte bei genauer Inspektion hochfrequenter Details (Text-Kanten, feine Texturen) detektierbar werden. Qualität 90 und höher ist für Archiv-JPEGs, bei denen Dateigröße irrelevant ist. Der Default von 80 sitzt am unteren Ende des Sweet Spots, angemessen für Batch-Web-Optimierung, wo das Ziel ist, so wenig Daten wie möglich zu liefern und gleichzeitig Bilder zu behalten, die akzeptabel aussehen. Für WebP ist der Default der Canvas-API toBlob('image/webp') Qualität 0,80; WebP bei Qualität 70 ist im Allgemeinen so visuell sauber wie JPEG bei Qualität 80. Für PNG ist „Qualität“ eine Fehlbezeichnung, PNG ist auf den Pixeldaten immer verlustfrei. Der Regler in diesem Tool hat keinen Effekt, wenn PNG als Ausgabeformat gewählt wird. Die entscheidende Lektion für Batch-Verarbeitung: eine einzelne Qualitätseinstellung ist selten korrekt für jedes Bild in einem gemischten Batch. Ein Ordner mit 50 Fotos, die mit derselben Kamera bei derselben Beleuchtung aufgenommen wurden, kann wahrscheinlich alle bei JPEG-Qualität 80 ohne Verlust gespeichert werden. Ein Ordner mit Screenshots, Fotos, Strichgrafiken und Logos durcheinander kann das nicht, ein Ein-Knopf-„alles in JPG-80 konvertieren“ wird die Screenshots in unleserliches Mosquito-Rauschen verwandeln. Teilen Sie die Eingabe in separate Batches auf, wenn der Inhalt variiert.

Lossy vs Lossless, die wichtigste Unterscheidung

Ein verlustfreier Encoder garantiert, dass die decodierte Ausgabe Bit-identisch zur kodierten Eingabe ist. PNG ist verlustfrei. WebP-lossless ist verlustfrei. TIFF (in seinen verlustfreien Modi) ist verlustfrei. Der Trade-off ist die Dateigröße: verlustfreie Encoder können imperzeptible Wahrnehmungsunterschiede nicht ausnutzen und müssen alles bewahren. Eine 1920×1080-Fotografie als verlustfreies PNG könnte 5 MB sein; dasselbe Foto als JPEG-Qualität-85 ist 200 KB. Das PNG ist Bit-perfekt; das JPEG ist visuell äquivalent. Ein verlustbehafteter Encoder verwirft Information, die das menschliche visuelle System am wenigsten wahrscheinlich bemerkt, hochfrequentes Detail, feine Chroma-Variation in gesättigten Farben, die vierte signifikante Stelle jedes Verlaufs. JPEG, lossy WebP und lossy AVIF tun das alle. Die Implikationen für einen Batch-Konverter sind konkret: verlustfrei zu verlustfrei (PNG zu PNG, oder PNG zu WebP-lossless) ist über beliebig viele Konvertierungen wirklich verlustfrei; lossy zu lossy bei gleicher Qualität (JPEG-85 zu JPEG-85) ist nicht verlustfrei, jede Re-Kodierung wendet einen weiteren Quantisierungsschritt an, wiederholen Sie das 10-mal und das Ergebnis ist sichtbar degradiert; lossy zu verlustfrei (JPEG zu PNG) friert die bestehenden Artefakte an Ort und Stelle ein, degradiert sie aber nicht weiter; verlustfrei zu lossy führt verlustbehaftete Kompression im Moment der Konvertierung ein, und es gibt keine Möglichkeit, das verworfene Detail später wiederherzustellen. Nutzer führen oft eine Konvertierung erneut aus und erwarten, dass sie ein No-op ist. Außerhalb des verlustfrei-zu-verlustfrei-Falls ist sie es nicht.

EXIF, IPTC, XMP, und warum dieses Tool sie entfernt

JPEG- und HEIC-Dateien von Kameras und Telefonen tragen einen EXIF-Block, Exchangeable-Image-File-Format-Metadaten, die im Bild-Header eingebettet sind. EXIF enthält Kameramodell, Objektiv, Belichtungseinstellungen, Datum und Uhrzeit, Softwareversion und am folgenreichsten die GPS-Koordinaten, wo das Foto aufgenommen wurde (wenn Standortdienste zur Aufnahmezeit aktiviert waren). IPTC-Metadaten fügen Bildunterschrift, Byline, Copyright und Schlüsselwörter hinzu. XMP, ursprünglich von Adobe, ist ein XML-basiertes Superset, das die älteren Formate subsumiert und das ist, was Lightroom und Photoshop verwenden. Die Datenschutz-Implikationen sind erheblich. Ein Foto, auf einem iPhone mit aktiviertem Standort aufgenommen, bettet GPS-Koordinaten auf wenige Meter genau ein. Es in einem Forum, in einem E-Mail-Anhang oder über einen persönlichen Blog zu teilen kann die Hausadresse des Fotografen, die Schule seines Kindes, seinen Arbeitsplatz, seine Wanderroute offenlegen. Große soziale Plattformen (Facebook, Instagram, Twitter/X) entfernen EXIF beim Hochladen, bevor sie das Bild an andere Nutzer ausliefern, aber sie lesen und speichern die Original-Metadaten selbst. Kleinere Foren, WordPress-Blogs, Discord, E-Mail-Clients und direkte Datei-Übertragungen lassen EXIF intakt. Die Re-Kodierung über die Canvas-API (das von diesem Tool genutzte Backend) verwirft alle EXIF-, IPTC- und XMP-Metadaten standardmäßig. Die Ausgabe ist ein sauberes Bild ohne eingebettete Provenienz, ein Datenschutz-Feature und ein Nebeneffekt der Canvas-Pipeline (das Canvas speichert nur Pixeldaten; es hat keinen Begriff von Metadaten zu bewahren). Nutzer, die Metadaten bewahren wollen (Fotografen, die Belichtungsdaten archivieren, Content-Workflows, in denen Copyright mit der Datei reisen muss), brauchen ein anderes Tool, typischerweise ImageMagicks convert oder eine dedizierte EXIF-bewusste Bibliothek. Dieser Konverter schneidet andersherum: er ist Metadaten-strippend per Design, was genau das ist, was ein datenschutzbewusster Nutzer will, wenn er Bilder an ein Forum schickt, in dem er nicht möchte, dass seine GPS-Koordinaten ihm folgen.

Transparente Hintergründe, die PNG-zu-JPEG-Wahl

PNG unterstützt einen Pixel-für-Pixel-Alpha-Kanal: jedes Pixel hat eine Opazität von 0 (vollständig transparent) bis 255 (vollständig undurchsichtig). JPEG hat keinen Alpha-Kanal. Ein PNG mit Transparenz in JPEG zu konvertieren erzwingt eine Wahl: was sollen die transparenten Pixel werden? Der Default der Canvas-API ist, gegen transparentes Schwarz zu komponieren, sodass das resultierende JPEG transparente Pixel zu undurchsichtigem Schwarz auflöst. Ein Logo auf transparentem Hintergrund, PNG-zu-JPEG konvertiert, kommt mit schwarzen Ecken um das Logo heraus, praktisch nie, was der Nutzer wollte. Die Mitigation ist, das Canvas mit einer gewählten Hintergrundfarbe zu füllen (Weiß ist der typische Default), bevor das Bild darüber gezeichnet wird. Nutzer, die Transparenz bewahren müssen, sollten PNG oder WebP als Ausgabeformat wählen. WebP unterstützt Transparenz in beiden Modi (verlustfrei und lossy), was es zur modernen Wahl macht, wenn die Quelle Transparenz hat und das Ziel effizient sein muss, ein 50-KB-PNG mit transparentem Hintergrund könnte zu einem 12-KB-WebP-lossy mit transparentem Hintergrund werden, während der Alpha-Kanal erhalten bleibt.

Wie die Konvertierung in Ihrem Browser läuft

Die Behauptung „alles läuft in Ihrem Browser“ stützt sich auf drei Web-Plattform-APIs, die erst kürzlich mächtig genug geworden sind, um einen Batch-Bildkonverter zu einem glaubwürdigen Client-Side-Produkt zu machen. FileReader- und Blob-APIs: wenn Sie Dateien in die Upload-Zone fallen lassen, ist jede File eine Subklasse von Blob, die entweder readAsDataURL() (älteres Callback) oder file.arrayBuffer() (Promise-basiert) exponiert. Speziell für Bilder ist der einfachere Weg, eine Blob-URL mit URL.createObjectURL(file) zu konstruieren und sie einem frischen Image-Element zuzuweisen, wodurch der eingebaute Bilddecoder des Browsers JPEG, PNG, GIF, WebP und BMP nativ handhabt. Die Canvas-API: sobald ein Image geladen ist, ist die Konvertierung ein Zwei-Schritt-Tanz, zeichnen mit ctx.drawImage(img, 0, 0), dann das Canvas zurücklesen mit canvas.toBlob(callback, type, quality). Der Type-Parameter ist eine MIME-Zeichenkette ('image/png', 'image/jpeg', 'image/webp'); der Quality-Parameter ist eine Zahl zwischen 0 und 1 für verlustbehaftete Formate. OffscreenCanvas und Web Workers: für große Batches blockiert das gesamte Canvas-Arbeit auf dem Hauptthread die UI. Die moderne Lösung ist OffscreenCanvas, das Canvas-Operationen in einem Worker-Kontext exponiert und selbst über postMessage ohne Kopieren an einen Web Worker übertragbar ist. Der Worker führt die Decode-Rasterise-Encode-Pipeline in einem separaten Thread aus und hält die Seite reaktionsfähig. Zusammen lassen diese APIs einen 50-Datei-Batch in Sekunden laufen, ohne Scrollen oder Klicken zu blockieren. JSZip (eine reine JavaScript- und MIT-lizenzierte Bibliothek) handhabt das finale ZIP-Packen vollständig im Speicher, bevor der Speichern-Dialog des Browsers feuert. Kein Upload, kein Server-Zip, keine temporäre Datei auf der Festplatte. Vor einem Jahrzehnt wäre ein Batch-Bildkonverter, der im Browser läuft, eine Kuriosität gewesen. WebAssembly-Performance, OffscreenCanvas-Parallelismus und moderne Telefon-RAM (6-12 GB) und Kernzahlen (6-8 CPUs) haben dieses Bild umgekehrt. Das Datenschutz-Argument schließt den Fall: serverseitige Konverter erfordern das Hochladen Ihrer Bilder auf eine Drittanbieter-Maschine, und selbst mit einer skrupulösen Lösch-Policy ist der Upload selbst ein Netzwerkereignis, das geloggt, abgefangen oder kompromittiert werden kann. Ein Nur-Browser-Konverter sendet nie ein Byte.

Häufige Fragen

Welche Bildformate werden unterstützt?

Der Konverter verarbeitet die meisten gängigen Formate (JPG, PNG, GIF, WebP, BMP, TIFF) und konvertiert sie in PNG, JPG oder WebP.

Kann ich die Qualität für JPG und WebP anpassen?

Ja. Nutzen Sie den Qualitätsregler, um die Kompression anzupassen (0-100). Höhere Werte bedeuten bessere Qualität, aber größere Dateien.

Wie lade ich mehrere Dateien herunter?

Wählen Sie „Alles als ZIP herunterladen", um alle konvertierten Bilder in einer einzigen ZIP-Datei zu bündeln, bequem zum Herunterladen und Speichern.

Warum ist die Grenze 50 Dateien pro Batch?

Es ist eine Speicher-Obergrenze. Jedes Bild muss in RAM als rohe Pixeldaten dekodiert werden, bevor das Canvas es re-kodieren kann. Ein 12-Megapixel-iPhone-Foto dekodiert zu etwa 36 MB Pixeldaten (12 Millionen Pixel × 3 Bytes RGB oder 4 Bytes RGBA). 50 davon auf einmal sind 1,8 GB Arbeitsspeicher. Die meisten Laptops handhaben das bequem; ältere Telefone nicht. Die 50-Datei-Obergrenze hält die Seite über Geräte hinweg vorhersagbar. Für größere Batches führen Sie das Tool in Runden aus, sagen wir, 50 Dateien, herunterladen, leeren, weitere 50 fallen lassen.

Gibt es eine Größenbeschränkung pro Datei?

Keine harte Obergrenze, die Grenze ist der verfügbare Speicher Ihres Geräts. Ein einzelnes 50-MP-Bild dekodiert zu etwa 150 MB Pixeldaten, was auf einem Desktop funktioniert, aber auf einem älteren Telefon Probleme bereitet. Als Faustregel: Dateien unter 10 MB konvertieren auf im Wesentlichen jedem Gerät reibungslos; Dateien über 50 MB werden auf Low-End-Mobile verlangsamen oder fehlschlagen. Wenn eine Konvertierung einfriert, aktualisieren Sie die Seite und versuchen Sie die Datei in einem kleineren Batch.

Entfernt der Konverter EXIF-Metadaten?

Ja, per Design. Die Canvas-Re-Kodierungs-Pipeline speichert nur Pixeldaten, sodass EXIF-, IPTC- und XMP-Metadatenblöcke (Kameramodell, Belichtungseinstellungen, GPS-Koordinaten, Copyright-Tags, Bearbeitungs-historie) den Round-Trip nicht überleben. Die Ausgabe ist ein sauberes Bild ohne eingebettete Provenienz, was ein Datenschutz-Gewinn ist, wenn Sie Fotos an Foren oder E-Mail-Kontakte teilen, bei denen Sie nicht möchten, dass GPS-Koordinaten folgen. Wenn Sie Metadaten brauchen (Fotografen, die Belichtungsdaten archivieren, Content-Workflows, die Copyright-Tags erfordern), ist dies das falsche Tool, verwenden Sie ImageMagicks convert oder eine dedizierte EXIF-bewusste Bibliothek, die Metadaten explizit bewahrt.

Was passiert mit transparenten Hintergründen, wenn ich PNG zu JPG konvertiere?

JPEG hat keinen Alpha-Kanal, also müssen transparente Pixel im Quell-PNG zu einer undurchsichtigen Farbe in der JPEG-Ausgabe werden. Das Canvas-Default-Verhalten ist, gegen einen farbigen Hintergrund (typischerweise Weiß) zu komponieren. Ein Logo auf einem transparenten PNG-Hintergrund, in JPEG konvertiert, verliert die Transparenz und nimmt die Hintergrundfüllung auf. Wenn Transparenz wichtig ist, wählen Sie PNG oder WebP als Ausgabeformat, beide bewahren Alpha. WebP-lossy bewahrt Transparenz bei dramatisch kleineren Dateigrößen als PNG und ist die moderne Wahl für transparente Web-Grafiken.

Werden meine Bilder irgendwohin hochgeladen?

Nein. Jeder Schritt (Dateiauswahl, Decode, Canvas-Re-Kodierung, ZIP-Packen, Download) läuft vollständig in Ihrem Browser über JavaScript. Es gibt keine serverseitige Verarbeitung. Sie können das überprüfen, indem Sie den Network-Tab der DevTools Ihres Browsers öffnen, während Sie konvertieren: es gibt keine ausgehenden Anfragen, die Bilddaten tragen. Die Seite ist sicher für sensitive Screenshots, Dokumentenscans, persönliche Fotos mit Standortmetadaten oder alles andere, was Sie nicht auf der Festplatte eines Fremden kopiert haben möchten.

Verwandte Tools