So funktioniert Dateikonvertierung direkt im Browser

Die meisten Online-Konverter laden Ihre Datei auf einen Server. Unserer kann das nicht: Jedes Tool auf dieser Seite führt die Konvertierung direkt in Ihrem Browser aus, mit JavaScript und WebAssembly. Diese Seite erklärt genau, was das bedeutet, wie Sie es selbst überprüfen können – und ebenso wichtig – was dadurch unmöglich wird.

Warum „kein Upload“ ein echter Architekturunterschied ist

Ein serverbasierter Konverter ist ein Thin Client: Ihr Browser sendet die Datei, der Server erledigt die Arbeit, und das Ergebnis kommt zurück. Dieses Design hat Vorteile – der Server kann jede Bibliothek ausführen, egal wie groß – und einen strukturellen Nachteil: Die Datei muss auf einer Infrastruktur existieren, die Sie nicht kontrollieren, zumindest für eine Weile. Aufbewahrungsfristen, Logs und Backups liegen alle außerhalb Ihres Blickfelds.

Diese Seite ist andersherum gebaut. Es gibt keinen Upload-Endpunkt. Die Seite lädt eine JavaScript-Bibliothek, die die Datei im Arbeitsspeicher dekodiert, sie umwandelt und das Ergebnis als lokalen Download zurückgibt. Wäre das Netzwerk nach dem Laden der Seite abgeschaltet, würde das Tool trotzdem funktionieren.

Die Pipeline, Schritt für Schritt

1. Lesen. Die Datei wird mit den Browser-APIs FileReader / File.arrayBuffer() gelesen. Sie wird zu Bytes im Speicher der Seite – nie zu einer Anfrage.
2. Dekodieren. Diese Bytes werden entweder von den eigenen Bild-Codecs des Browsers (über <img> oder createImageBitmap) oder von einer WebAssembly-Bibliothek dekodiert, die für Formate mitgeliefert wird, die der Browser nicht nativ unterstützt – etwa libheif für HEIC oder pdf.js für PDF-Seiten.
3. Umwandeln. Die dekodierten Daten werden in ein <canvas> gezeichnet oder im Speicher bearbeitet: skaliert, zugeschnitten, gedreht, neu eingefärbt, neu kodiert.
4. Kodieren. Das Canvas wird mit canvas.toBlob() in ein Binärformat zurückgeschrieben, oder ein Dokument wird mit einer reinen JavaScript-Bibliothek wie pdf-lib neu aufgebaut.
5. Ausliefern. Das Ergebnis wird zu einem Blob und einer Objekt-URL, die die Seite als Download auslöst. Nichts wird übertragen.

So prüfen Sie es selbst

Verlassen Sie sich nicht auf die Aussage dieser Seite. Öffnen Sie die Entwicklertools Ihres Browsers, wechseln Sie zum Netzwerk-Panel und konvertieren Sie eine Datei. Schauen Sie dann, was passiert ist:

• Sie sehen Anfragen für die Seite, das Stylesheet, die JavaScript-Bibliotheken und das Analytics-Tag – alle über URL.
• Sie sehen keine Anfrage, deren Body Ihre Datei ist. Es gibt kein POST mit einigen Megabyte Nutzlast.
• Haken Sie im selben Panel „Offline“ an, nachdem die Seite geladen ist, und konvertieren Sie erneut. Es funktioniert weiterhin, was mit einem Server unmöglich wäre.

Wenn Sie es genauer wissen wollen, beobachten Sie den Speicher- oder Performance-Tab, während Sie eine große PDF-Datei konvertieren, und Sie sehen, dass die Allokation im Prozess der Seite selbst stattfindet.

Was ein Browser gut kann

• Bilder dekodieren und kodieren. JPEG, PNG, WebP, GIF und AVIF werden nativ dekodiert, und das Canvas kann die meisten davon wieder kodieren.
• Pixel-Transformationen. Skalieren, Zuschneiden, Drehen, Compositing, Farbanpassung – alles hardwarebeschleunigt über die Canvas-API.
• PDF-Seiten rendern. pdf.js ist ein vollständiger PDF-Renderer in JavaScript, sodass eine Seite in jeder Auflösung in ein Canvas umgewandelt werden kann.
• Dokumente zusammensetzen. pdf-lib kann PDF-Strukturen erzeugen und verändern – zusammenführen, teilen, umsortieren, Overlays hinzufügen – ohne etwas zu rendern.
• Textverarbeitung. JSON, CSV, Markdown, Base64 und ähnliche Formate kosten in JavaScript nichts.

Was ein Browser nicht kann

Ehrlich darüber zu sein ist wichtiger, als Fähigkeiten aufzulisten, denn genau diese Grenzen sind der Grund, warum sich manche Konvertierungen hier anders verhalten als bei einem serverbasierten Tool.

• Die eingebetteten Bilder einer PDF an Ort und Stelle neu komprimieren. Ein Server-Optimierer kann jedes Bild in einer PDF dekodieren, effizienter neu kodieren und die Datei mit intakter Textebene neu aufbauen. Im Browser ist das nicht praktikabel, weshalb unsere PDF-Komprimierung zwei Modi anbietet: neu paketieren (der Text bleibt, die Einsparung ist bescheiden) oder die Seiten rastern (große Einsparung, der Text wird zu einem Bild).
• AVIF in jedem Browser kodieren. Ein AVIF zu erzeugen erfordert den Encoder des Browsers, den es heute nur in Chromium-basierten Browsern gibt. In Firefox und Safari muss ein Konverter das sagen, statt stillschweigend etwas anderes zu erzeugen.
• TIFF oder HEIC ohne Hilfe dekodieren. Browser liefern diese Codecs nicht mit, also muss ein WebAssembly-Decoder heruntergeladen werden – rund 600 KB für den HEIC-Decoder, einmal abgerufen und dann gecacht.
• GIF kodieren. Browser dekodieren GIF, kodieren es aber nicht, daher braucht eine GIF-Ausgabe einen JavaScript-Encoder.
• OCR ohne Modell. Text aus einem Scan zu lesen braucht ein trainiertes Erkennungsmodell von mehreren Megabyte; das ist eine andere Art von Funktion, keine Formatkonvertierung.
• Beliebig große Dateien verarbeiten. Alles lebt im Arbeitsspeicher der Seite, die praktische Obergrenze ist also der RAM Ihres Geräts und kein Server-Kontingent. Ein paar hundert Megabyte funktionieren auf einer modernen Maschine; mehrere Gigabyte nicht.

Warum wir die Grenzen veröffentlichen

Ein Tool, das behauptet, keine Grenzen zu haben, verbirgt meist etwas. Wenn wir sie veröffentlichen, können Sie entscheiden, ob eine bestimmte Konvertierung hier überhaupt sinnvoll ist; außerdem lassen sich die Zahlen auf den Tool-Seiten – die Auflösung, die Qualität, die Dateigröße – gegen das prüfen, was die Implementierung tatsächlich tut.

Wenn Sie über browserbasierte Tools schreiben und eine Quelle zitieren möchten, ist diese Seite genau dafür gedacht. Keine Erlaubnis nötig.

← ← Zurück zu den Tools