Browserbasierte Dateikonvertierung: So funktioniert sie und warum deine Dateien privat bleiben

Lade eine Datei zu einem serverbasierten Konverter hoch und drei Dinge passieren. Deine Datei reist über das Netzwerk zu einer IP-Adresse, die du nicht kontrollierst. Ein Prozess auf diesem Server dekodiert sie. Dann, je nach Aufbewahrungsrichtlinie der Seite, liegt die Datei für Minuten bis für immer auf der Festplatte.

Mach dasselbe in einem Browser-Tab und die Datei verlässt niemals den Arbeitsspeicher deines Rechners. Der Dekoder läuft in einer WebAssembly-Sandbox, die die Browser-Engine durchsetzt. Das Netzwerk wird nie berührt.

Das ist kein Richtlinien-Unterschied. Es ist ein architektonischer. Ein serverbasierter Konverter kann versprechen, deine Dateien zu löschen; ein browserbasierter kann sie nicht leaken, weil er sie von vornherein nie erhält.

Die Architektur

Vier Schichten ermöglichen die clientseitige Konvertierung:

Schicht 1: Dateizugriff

Wenn du eine Datei in einen Browser-Tab ziehst, gibt das DragEvent oder <input type="file"> JavaScript ein File-Objekt. Ein File ist nicht der Inhalt der Datei. Es ist eine Referenz: ein Name, eine Größe, ein MIME-Typ und eine Methode (file.arrayBuffer()), die Bytes bei Bedarf von der Festplatte in den Speicher liest.

Bis diese Methode aufgerufen wird, haben sich null Bytes bewegt. Die Datei liegt auf deinem Dateisystem. Die Dateiauswahl des Browsers ist ein Dialog auf Betriebssystemebene; die Webseite sieht nur das File-Objekt, das der Benutzer explizit ausgewählt hat.

Schicht 2: Formaterkennung

Die ersten Bytes jeder Datei identifizieren ihr Format zuverlässig. Ein JPEG beginnt mit FF D8 FF. Ein PNG beginnt mit 89 50 4E 47. Eine HEIC-Datei enthält eine ftyp-Box mit einer heic- oder heif-Marke bei Offset 8.

Den Header einer Datei zu lesen (typischerweise die ersten 32 Bytes) reicht aus, um zu bestätigen, was sie tatsächlich ist, unabhängig von der Erweiterung. Diese Prüfung läuft, bevor irgendein Dekoder die Pixeldaten anfasst. Wenn der Header nicht übereinstimmt, wird die Datei sofort abgelehnt. Keine verschwendete CPU, keine verwirrenden Fehlermeldungen mitten in einer Dekodierung.

Schicht 3: Dekodierung

Rohe Bytes werden durch einen Dekoder zu Pixeln. Welcher Dekoder hängt vom Format ab:

JPEG, PNG, WebP, BMP: der Browser liefert native Dekoder für diese. createImageBitmap() übergibt die komprimierten Bytes an den Codec der Plattform (Windows Imaging Component unter Windows, Core Graphics unter macOS, Skia unter Linux/ChromeOS) und gibt rohe Pixeldaten zurück. Dieser Pfad ist schnell, hardwarebeschleunigt wo das Betriebssystem es unterstützt, und benötigt keinen zusätzlichen Code.
HEIC: kein Browser außer Safari liefert einen nativen HEIC-Dekoder. Unser Konverter bündelt libheif, eine C-Bibliothek, kompiliert zu WebAssembly. Die .wasm-Binärdatei (~1,2 MB komprimiert) wird einmal heruntergeladen und gecacht. Sie dekodiert HEIF/HEIC-Dateien zu rohen RGB-Pixeln vollständig innerhalb der WASM-Sandbox.
PDF: PDF.js (Mozillas PDF-Renderer) rendert jede Seite in der angeforderten Auflösung auf ein Canvas. Kein serverseitiges Rendering. Die PDF verlässt nie den Browser.

Jeder Dekoder liest aus dem Speicher und schreibt in den Speicher. Keiner öffnet Sockets. Insbesondere die WASM-Sandbox kann keine Netzwerkanfragen stellen: der Browser stellt WebAssembly-Modulen keine Netzwerk-APIs zur Verfügung. Selbst wenn der C-Code socket() aufrufen würde, würde die Sandbox dies abfangen.

Schicht 4: Kodierung

Rohe Pixel gehen in den 2D-Kontext eines <canvas>-Elements. canvas.toBlob() oder canvas.toDataURL() ruft den eingebauten Encoder des Browsers für JPG-, PNG- oder WebP-Ausgabe auf. Der Encoder ist plattformnativer Code: derselbe Codepfad, den dein Betriebssystem zum Speichern von Screenshots verwendet.

Die Ausgabe ist ein Blob, ein In-Memory-Byte-Puffer. Er wird an einen Download-Link übergeben oder in ein in JavaScript erstelltes ZIP-Archiv gepackt. Zu keinem Zeitpunkt berührt irgendein Byte einen Netzwerk-Socket.

Was der Browser durchsetzt

Webseiten laufen in einer Sandbox, die der Browser auf Engine-Ebene aufrechterhält. Das ist keine höfliche Vereinbarung. Es wird durch Prozessisolation durchgesetzt:

Renderer-Prozess: die JavaScript-Engine, das DOM und die WASM-Laufzeit leben in einem sandboxed-Prozess ohne direkten Dateisystem- oder Netzwerkzugriff. Er kommuniziert mit der Außenwelt über IPC zum Browser-Prozess.

Site-Isolation: moderne Browser stecken jeden Ursprung in seinen eigenen Renderer-Prozess. Deine Dateien in file-convert-factory.org sind für JavaScript, das auf einer anderen Domain läuft, unsichtbar.

WASM-Sandbox: WebAssembly-Module sehen einen flachen linearen Speicherpuffer und sonst nichts. Keine Dateisystem-APIs, kein fetch außer es wird explizit aus JavaScript importiert, kein Zugriff auf das DOM oder andere Browser-APIs. Das Schlimmste, was ein kompromittiertes WASM-Modul tun könnte, ist, seinen eigenen Speicher zu beschädigen und den Tab zum Absturz zu bringen.

Ein serverbasierter Konverter läuft als privilegierter Prozess auf dem Betriebssystem des Servers. Er kann von der Festplatte lesen, auf die Festplatte schreiben, Netzwerkverbindungen öffnen und Kindprozesse starten. Das Sicherheitsmodell hängt von der Kompetenz und den Absichten des Serverbetreibers ab. Die Browser-Sandbox hängt nur von der Korrektheit der Browser-Engine ab, und Browser-Sandboxen gehören zu den am stärksten geprüften Sicherheitsgrenzen in der Software.

Was serverbasierte Konverter versprechen (und was nicht)

Serverbasierte Konverter sind nicht per se böswillig. Viele werden von gutmeinenden Teams betrieben. Das Problem ist strukturell:

Der Upload-Schritt ist eine Kopie. Deine Datei existiert jetzt an zwei Orten. Du kontrollierst eine Kopie. Jemand anderes kontrolliert die andere.
Löschung ist ein Versprechen. „Wir löschen Dateien nach 24 Stunden" bedeutet, der Log-Zeile, dem Cron-Job, dem Backup-System und jedem Mitarbeiter mit Serverzugriff zu vertrauen. Nichts davon ist von außen überprüfbar.
Metadaten reisen mit der Datei. Die EXIF-Daten deines Fotos (GPS-Koordinaten, Kamera-Seriennummer, Zeitstempel) sind Teil der Datei-Bytes. Wenn die Datei hochgeladen wird, werden die Metadaten hochgeladen. Unser EXIF-Privatsphäre-Leitfaden behandelt genau, was darin enthalten ist und wie man es entfernt. Die Kurzversion: Jeder Konverter auf dieser Seite entfernt Metadaten, weil er Pixel dekodiert und neu kodiert und dabei alles fallen lässt, was keine Bilddaten sind.
HTTPS schützt die Leitung, nicht den Endpunkt. TLS verschlüsselt den Upload während der Übertragung. Es tut nichts gegen das, was mit der Datei nach ihrer Ankunft passiert.

Die Privatsphäre-Garantie eines browserbasierten Konverters ist enger, aber stärker. Sie besagt: Deine Dateien verlassen dein Gerät nicht, weil es keinen Codepfad gibt, auf dem sie das könnten. Das ist überprüfbar. Öffne den Netzwerk-Tab in den DevTools, während du eine Datei konvertierst. Du wirst sehen, wie die WASM-Binärdatei einmal geladen wird, dann nichts. Null Bytes hochgeladen. Keine Anfragen an /api/convert. Kein WebSocket-Verkehr. Die Konvertierung findet vollständig innerhalb des Renderer-Prozesses statt.

Selbst überprüfen

Du musst niemandem beim Wort nehmen. Öffne Chrome DevTools (F12), wechsle zum Netzwerk-Tab und konvertiere eine Datei auf einer beliebigen Tool-Seite. Die einzige Netzwerkaktivität, die du sehen wirst:

Das HTML, CSS und JavaScript der Seite: einmal beim ersten Besuch geladen.
Die WASM-Binärdatei (für HEIC-Konverter): einmal geladen, danach gecacht.
Analyse-Anfragen (falls du sie nicht blockiert hast).

Keine Dateidaten verlassen den Browser. Die Content-Length jeder Anfrage wird in Kilobyte gemessen, nicht in Megabyte. Das ist von jedem unabhängig überprüfbar, der DevTools öffnen kann.

Dasselbe kann man von einem serverbasierten Dienst nicht behaupten. Du lädst die Datei hoch, bekommst ein Ergebnis und vertraust darauf, dass der Server sie gelöscht hat.