Browserbasierte Datei-Tools erledigen die Arbeit innerhalb der Seite statt auf einem Server. Deine Datei wird vom File API von der Festplatte gelesen, von einer WebAssembly-Engine wie qpdf oder FFmpeg verarbeitet, die im Tab läuft, und als Download zurückgeschrieben. Es gibt keinen Upload-Schritt, es wird also nichts gesendet.
Die Architektur hat drei Teile. Die APIs File und Blob bewegen Bytes zwischen deiner Festplatte und der Seite, ohne einen Netzwerk-Roundtrip. WebAssembly führt Engines aus, die ursprünglich für den Desktop geschrieben wurden, weshalb die Ergebnisse zu einem Desktop-Tool passen und nicht zu einer vereinfachten Web-Näherung. Canvas, Web Worker und MediaRecorder decken die Aufgaben ab, die Zeichnen, Hintergrundverarbeitung oder eine Kamera brauchen. Der Kompromiss ist, dass der erste Durchlauf die Engine herunterlädt und alles in den Speicher eines Tabs passen muss.
Die meisten Menschen begegnen dieser Idee in einer Datenschutzzeile auf einer Tool-Seite: Dateien verlassen dein Gerät nie. Dieser Satz ist entweder wahr oder nicht, und er wird von der Architektur entschieden und nicht von der Absicht. Dieser Leitfaden erklärt, was ein Browser heute tatsächlich ausführen kann, warum der Upload-Schritt verschwindet, wenn man so baut, und welche Kosten das mit sich bringt.
Bild-Kompressor
Ein konkretes Beispiel. Canvas und OxiPNG laufen im Tab, die Größen vorher und nachher werden nebeneinander angezeigt, und die Datei wird nie hochgeladen.
Zwei Architekturen: der Server-Roundtrip und der lokale Tab
Die meisten Online-Konverter folgen derselben Form. Dein Browser sendet die Datei mit einem HTTP-Upload an einen Server, der Server führt ein Tool wie ImageMagick oder ein headless FFmpeg aus, und ein Download-Link kommt zurück. Die Arbeit ist real und oft schnell, aber die Datei muss deine Maschine verlassen, damit das geschieht, und sie bleibt auf dieser Maschine, solange der Betreiber sie behält.
Ein browserbasiertes Tool behält dieselben Schritte und lässt den Server weg. Das Lesen der Datei, das Ausführen der Engine und das Schreiben des Ergebnisses geschehen alle im Tab. Das ist keine kleine Abwandlung des Upload-Modells. Es beseitigt eine ganze Klasse von Problemen, weil es keinen Transfer zum Abfangen, keine Warteschlange zum Warten und kein Aufbewahrungsfenster zum Nachlesen gibt.
| Schritt | Serverbasiertes Tool | Browserbasiertes Tool |
|---|---|---|
| Die Datei lesen | In deren Speicher kopiert | Vom File API gelesen, bleibt lokal |
| Verarbeitung | Deren CPU, meist in der Warteschlange | Deine CPU, im Tab |
| Ergebnis | Ein Download-Link, der abläuft | Ein Blob-Download, sofort bereit |
| Wer die Datei lesen kann | Jeder mit Zugriff auf deren Speicher | Nur du |
Was der Browser tatsächlich ausführt
Ein kurzer Rundgang durch den Stack, denn diese Fähigkeiten sind es, die das Datenschutzversprechen möglich machen, und nicht eine aufgesetzte Marketingebene.
WebAssembly bringt Desktop-Engines in den Tab
WebAssembly ist ein kompaktes Binärformat, das in einer sandboxed virtuellen Maschine mit nahezu nativer Geschwindigkeit läuft. In C, C++ oder Rust geschriebene Engines werden dorthin kompiliert und als gewöhnliche Dateien ausgeliefert: qpdf für PDF-Verschlüsselung, FFmpeg für Video und Audio, Tesseract für optische Zeichenerkennung, pdf-lib zum Erstellen und Bearbeiten von PDFs und OxiPNG für verlustfreie PNG-Optimierung. PDF.js übernimmt das PDF-Rendering und die Textextraktion. Weil dies dieselben Engines sind, die auf dem Desktop verwendet werden, ist die Ausgabe keine Web-Näherung: Ein Video, das der FFmpeg-Build in deinem Tab codiert, ist die Ausgabe von FFmpeg.
Canvas und die Bildpipeline
Bilder sind die eine Kategorie, die kein WebAssembly braucht. Die Canvas API bietet dieselbe Zeichenfläche, die ein nativer Bildeditor verwendet. createImageBitmap decodiert eine Datei, ein Canvas hält die Pixel, und toBlob codiert das Ergebnis zurück zu PNG, JPEG, WebP oder AVIF. Zuschneiden, Größe ändern, Wasserzeichen und Formatkonvertierung sind alles Pixeloperationen auf dieser Fläche. Der Bild-Kompressor paart es mit OxiPNG für die PNG-Ausgabe, das die Datei verlustfrei neu komprimiert, statt Qualität wegzuwerfen.
Web Worker halten die Oberfläche am Leben
Schwere Arbeit im Hauptthread friert die Seite ein, deshalb laufen die langen Aufträge in einem Web Worker, einem Hintergrundthread ohne Zugriff auf das DOM. Die Video-Tools übergeben die Arbeit an FFmpeg in einem Worker und erhalten Logzeilen und Fortschrittsereignisse zurück, weshalb sich der Fortschrittsbalken weiterbewegt, während der Encoder beschäftigt ist. Tesseract folgt demselben Muster. Bemerkenswert ist, dass das OCR-Setup hier einen Single-Threaded-Engine-Build verwendet, es braucht also nicht die SharedArrayBuffer-Header, die viele WebAssembly-Tools vom Server verlangen.
File und Blob bewegen die Bytes
Das File API ist das, was den Upload ersetzt. Wenn du eine Datei auf die Seite ziehst, erhält JavaScript ein File-Objekt, und file.arrayBuffer() liest ihre Bytes bei Bedarf in den Speicher. Das Ergebnis ist ein Blob, der zu einer temporären lokalen URL werden oder direkt an einen Download übergeben werden kann. Die Bytes reisen von der Festplatte in den Speicher und zurück, und es gibt in dieser Schleife keinen Codepfad, der mit einem Netzwerk spricht. Das ist auch der Grund, warum ein Browser-Tool kein vom Server auferlegtes Upload-Größenlimit hat, sondern nur das Speicherlimit des Geräts.
Warum lokale Verarbeitung bedeutet, dass nichts hochgeladen wird
Die Behauptung ist leicht aufzustellen und leicht zu überprüfen. Ein Upload ist eine Netzwerkanfrage, die deine Datei trägt, und ein Browser-Tool stellt niemals eine, weil am anderen Ende nichts ist, das sie braucht. Die einzigen Anfragen, die eine Seite wie diese stellt, gelten ihrem eigenen Code und ihren Ressourcen: das HTML, das Stylesheet, die Engine bei der ersten Nutzung und die Schriftart.
Du musst das nicht auf Treu und Glauben hinnehmen. Öffne die Entwicklertools des Browsers, wechsle zum Netzwerk-Panel, leere es, verarbeite dann eine Datei und schau zu. Die Anfragen, die erscheinen, tragen Code und Ressourcen. Keine davon trägt dein Dokument, und wenn du dich vom Netzwerk trennst, nachdem die Engine geladen ist, funktioniert die Verarbeitung weiter. Es gibt einen längeren, schrittweisen Leitfaden zu der Prüfung, ob ein Tool deine Datei hochlädt wenn du die vollständige Vorgehensweise willst.
| Anfrage, die du sehen wirst | Was es transportiert |
|---|---|
| Die Seite, ihr CSS und ihr JavaScript | Website-Code, nicht deine Datei |
| Die Engine, bei der ersten Nutzung | Ein kompiliertes Tool, danach zwischengespeichert |
| Webschriftarten | Eine Schriftart |
| Analytics-Skript | Ein Seitenaufruf, keine Dateibytes |
Die letzte Zeile ist wichtig, weil sie die übliche Quelle falschen Alarms ist. Analytics laden auf der Seite und melden, dass eine Seite aufgerufen wurde, nicht den Inhalt deines Dokuments. Diese Seite selbst lädt Google Tag Manager, weshalb das Netzwerk-Panel ein Skript von Google zeigt. Diese Anfrage meldet einen Seitenaufruf und ist kein Dateitransfer.
Was du dafür bezahlst
Lokale Verarbeitung ist nicht kostenlos, und die ehrliche Version der Sache ist es wert, klar gesagt zu werden. Drei Kosten treten auf, und ein vierter Punkt erklärt, wo der Browser an seine Grenze stößt.
- Der erste Durchlauf lädt herunter. Jede Engine wird einmal geholt: etwa 30 MB für den FFmpeg-Kern hinter den Video- und Audio-Tools, etwa 6,7 MB für die OCR-Engine und die englischen Daten, etwa 1,3 MB für die PDF-Engine und etwa 1,4 MB für den PDF.js-Worker, der für Seitenvorschauen genutzt wird. Nichts davon ist deine Datei, und alles davon wird zwischengespeichert, aber ein Kaltstart auf einer langsamen Verbindung ist ein langsamer Start.
- Der Speicher ist die Obergrenze. Alles, was die Engine liest und schreibt, lebt in einem Tab. Ein Desktop-Tool streamt eine große Datei von der Festplatte, während ein Browser-Tab sie hält, ein riesiges Video oder PDF kann also den Speicher erschöpfen, bevor es fertig ist. Manche Tools nennen aus diesem Grund eine harte Obergrenze, etwa das Limit von 50 MB beim PDF-Entsperr-Tool.
- Ein Server kann schneller sein. Die Videocodierung ist CPU-gebunden, und eine dedizierte Maschine mit mehr Kernen und wärmerem Cache schlägt einen Laptop-Tab. Der Browser-Build setzt außerdem auf Software-Encoding statt auf einen Hardwareencoder, er bekommt also nicht die GPU-Beschleunigung, die ein nativer Build nutzen kann.
- Einige Aufgaben brauchen trotzdem einen Server. Hintergrundentfernung, Objektlöschung und generative Bildverbesserung hängen von großen Modellen ab, die kein vernünftiges Download-Budget abdeckt. Diese drei werden von Cloud AI behandelt, und sie laden das Bild tatsächlich hoch. Alles andere auf der Seite ist lokal.
Bei einem Dokument von ein paar Megabyte oder einem Clip von einer Minute sind diese Kosten nicht spürbar, und der Kompromiss erkauft Privatsphäre und das Fehlen von Kontingenten. Für eine zweistündige 4K-Aufnahme ist ein Desktop-Tool oder ein Server-Job die bessere Wahl, und die ehrliche Antwort ist, das auch zu sagen.
Dasselbe Muster über die ganze Tool-Sammlung
Die Startseite gruppiert die Tools in fünf Abschnitte, und die Architektur ist in jedem dieselbe. PDF-Arbeit läuft mit qpdf, pdf-lib und PDF.js. Zum Beispiel PDF zusammenfügen verbindet Dateien mit pdf-lib, während PDF zu Text extrahiert Text mit PDF.js und greift nur bei gescannten Seiten auf Tesseract zurück. Bildarbeit läuft mit Canvas und OxiPNG. Video und Audio laufen mit FFmpeg, wobei Video-Kompressor und die Audio-Tools sich eine einzige Engine teilen. OCR läuft auf Tesseract. Die drei Cloud AI-Tools sind die Ausnahme, und die Seite kennzeichnet sie als solche, statt die Grenze zu verwischen.
Das praktische Fazit ist, dass du über jedes Tool auf dieselbe Weise nachdenken kannst. Wenn es eine echte Engine nennt und sie im Tab ausführt, bleibt die Datei, wo sie ist. Wenn es ein größeres Modell braucht, als ein Browser herunterladen kann, wird es sagen, dass es hochlädt, und es sollte das auf der Seite sagen und nicht in einer Fußnote.
