Ein HEIC-Foto wird zu JPG, eine WAV-Datei entsteht aus einer MP3, und nichts davon wird hochgeladen. Klingt nach Magie, ist aber handfeste Technik: WebAssembly. Wie browserbasierte Konvertierung wirklich funktioniert, wo ihre Grenzen liegen und warum sie für den Datenschutz ein echter Gewinn ist.

Das klassische Modell: Upload, Server, Download

Traditionell laufen Online-Konverter so: Du lädst deine Datei auf einen fremden Server hoch, dort rechnet ein Programm wie FFmpeg oder ImageMagick, und du bekommst das Ergebnis zurück.

Das funktioniert, hat aber drei Probleme. Deine Datei verlässt dein Gerät und liegt zumindest kurz auf fremder Infrastruktur. Bei großen Dateien wartest du doppelt: einmal beim Hoch-, einmal beim Herunterladen. Und der Betreiber trägt Server- und Speicherkosten, die mit jedem Nutzer steigen.

Das moderne Modell: alles bleibt im Browser

Seit einigen Jahren gibt es einen Weg, die eigentliche Rechenarbeit komplett auf dein Gerät zu verlagern, nämlich in den Browser-Tab selbst. Möglich macht das WebAssembly.

WebAssembly (kurz Wasm) ist ein offizieller W3C-Standard und wird von Chrome, Firefox, Edge und Safari unterstützt. Es ist ein kompaktes Binärformat, in das sich Programme aus Sprachen wie C, C++ oder Rust kompilieren lassen. Im Browser läuft es dann mit nahezu nativer Geschwindigkeit. Der Clou: Ein über Jahrzehnte gewachsenes C-Programm muss nicht für den Browser neu geschrieben werden, sondern wird mit einer Compiler-Toolchain wie Emscripten einmal nach Wasm übersetzt.

Dazu kommt die Sandbox. Wasm-Code hat keinen Zugriff auf dein Betriebssystem oder Dateisystem. Er sieht nur das, was die Webseite ihm bewusst übergibt. Damit ist er in mancher Hinsicht sicherer als eine installierte Desktop-Anwendung.

Beispiel ffmpeg.wasm: FFmpeg im Browser-Tab

Das eindrucksvollste Beispiel ist ffmpeg.wasm, das komplette FFmpeg, kompiliert nach WebAssembly. Ein rund 31 MB großes Wasm-Modul enthält die FFmpeg-Bibliotheken (libavcodec, libavformat, libavfilter, libswscale, libswresample). Dieselben Kommandozeilen-Befehle, die sonst auf einem Server laufen, funktionieren damit direkt im Browser:

ffmpeg -i input.mp4 -c:v libvpx-vp9 output.webm

Der Ablauf einer Konvertierung sieht dann so aus:

Datei wird per Drag & Drop gewählt
        ↓
File API liest sie als ArrayBuffer in den Speicher
        ↓
Wasm-Modul erhält den Buffer in seinem virtuellen Dateisystem
        ↓
FFmpeg verarbeitet alles lokal im Tab
        ↓
Ergebnis-Buffer kommt zurück
        ↓
Browser bietet ihn als Blob-Download an

Die einzige Netzwerk-Anfrage der Seite ist das einmalige Laden des Wasm-Moduls. Danach wird es gecacht, und die eigentliche Datei wird nie übertragen.

Für Bilder läuft es oft noch leichtgewichtiger über die native Canvas-API des Browsers: Bild laden, in ein Canvas zeichnen, als JPG/PNG/WebP wieder ausgeben. Für Spezialformate wie HEIC kommt ein kleines Wasm-Modul hinzu, etwa ein libheif-Port.

Der Stolperstein: COOP- und COEP-Header

Es gibt einen technischen Haken, an dem viele Entwickler hängenbleiben. Für mehrfädige Verarbeitung braucht ffmpeg.wasm den SharedArrayBuffer, also gemeinsamen Speicher zwischen Haupt-Thread und Web Workern. Aus Sicherheitsgründen (Stichwort Spectre) geben Browser diesen nur in einem „cross-origin isolierten" Kontext frei.

Konkret muss der Server zwei Header senden:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Erst damit steht der schnelle, mehrfädige Modus zur Verfügung. Es gibt auch eine einfädige Variante des Cores, die ohne diese Header läuft, dafür aber langsamer. SharedArrayBuffer selbst wird von Chrome (ab 92), Firefox (ab 79) und Safari (ab 15.2) unterstützt, ist 2026 also faktisch überall verfügbar.

Die ehrlichen Grenzen

Browser-Konvertierung ist großartig, aber kein Allheilmittel:

  • Geschwindigkeit: WebAssembly läuft langsamer als ein natives Programm, je nach Codec und Gerät etwa 5- bis 20-mal. Der mehrfädige Core ist rund doppelt so schnell wie der einfädige, holt den Rückstand aber nicht ganz auf.
  • Speicher: Der Browser begrenzt den Arbeitsspeicher pro Tab. Sehr große Dateien wie ein langes 4K-Video können an diese Grenze stoßen.
  • Codecs: Patentbehaftete Formate fehlen im Standard-Build oft. HEVC- oder AV1-Encoding sind häufig nicht dabei; H.264-Decoding, VP9-Encoding und reine Formatkonvertierung funktionieren dagegen problemlos.

Aus genau diesen Gründen ist der pragmatische Weg ein hybrider: Was sich gut lokal rechnen lässt, allen voran Bilder, läuft im Browser. Was viel Rechenleistung oder Spezialbibliotheken braucht, etwa manche Dokumentkonvertierungen, bleibt sinnvoll serverseitig, dann aber mit sofortiger Löschung der Datei.

Warum das für den Datenschutz zählt

Der eigentliche Gewinn liegt nicht in der Technik, sondern in ihrer Konsequenz: Wenn eine Datei dein Gerät nie verlässt, kann sie auch nirgendwo gespeichert, protokolliert oder weitergegeben werden. Für Fotos mit Metadaten, für vertrauliche Dokumente, für alles unter DSGVO-Gesichtspunkten ist das ein fundamentaler Unterschied zum klassischen Upload-Konverter. Es gibt keine Übertragung, in die jemand hineinschauen könnte, und keine Kopie, die irgendwo „vergessen" wird.

Genau auf diesem Prinzip baut wandlio: Bild-Konvertierungen laufen lokal in deinem Browser, Dokumente serverseitig, und in beiden Fällen wird deine Datei immer gelöscht.

Selbst ausprobieren

Kein Account, kein Upload, kein Warten auf einen Server-Roundtrip.