Wie clientseitige PDF-Verarbeitung funktioniert (im Browser, ohne Upload)

“Läuft in deinem Browser” ist eine Behauptung, die fast jede PDF-Website irgendwo in ihrer Fußzeile aufstellt. Die meisten von ihnen laden deine Datei trotzdem hoch. Hier erfährst du, was tatsächlich zutreffen muss, damit diese Behauptung stimmt, und wie du es in unter einer Minute selbst überprüfst.

Die Architektur, die es möglich macht: WebAssembly

Echte PDF-Manipulation — Seiten zusammenführen, Bilder neu kodieren, einen verschlüsselten Datenstrom umschreiben — braucht dieselben systemnahen Bibliotheken, die native Apps verwenden. Browser können C/C++/Rust nicht direkt ausführen, aber sie können WebAssembly (WASM) ausführen: diese Bibliotheken, kompiliert in ein Binärformat, das der Browser mit nahezu nativer Geschwindigkeit ausführt.

Das ist der Unterschied zwischen einem clientseitigen Tool und einem “browserbasierten” Tool, das eigentlich nur ein hübscheres Upload-Formular ist. Eine Seite mit einer Drag-and-drop-Box und einem Fortschrittsbalken kann deine Datei trotzdem still an einen Server POSTen, sobald du sie hineinziehst. WASM ist das, was die eigentliche Verarbeitung — nicht nur die Oberfläche — lokal ablaufen lässt.

Warum es in einem Web Worker läuft, nicht im Hauptthread

Eine 100-seitige PDF-Datei zu dekodieren und neu zu schreiben ist echte CPU-Arbeit. Würde das auf dem Hauptthread des Browsers geschehen, würde die Seite einfrieren — kein Scrollen, kein Klicken, eine Warnung “Tab reagiert nicht” bei allem Größeren. Ein Web Worker erledigt diese Arbeit stattdessen auf einem Hintergrund-Thread, sodass die Oberfläche reaktionsfähig bleibt und du einen lebendigen Fortschrittsbalken statt eines eingefrorenen Tabs bekommst. Die Bytes der Datei werden in den Speicher gelesen, an den Worker übergeben, verarbeitet und zurückgegeben — alles innerhalb deines Browserprozesses. Nichts an diesem Ablauf erfordert oder profitiert von einem Server.

Was “kein Upload” tatsächlich ausschließt

Ist ein Tool wirklich clientseitig, folgen drei Dinge daraus, und alle drei sind überprüfbar:

• Kein Upload-Endpunkt. Es gibt kein /api/upload oder Ähnliches, das das Tool aufrufen könnte — weil es nichts gibt, das es aufrufen kann.
• Keine Verarbeitungsverzögerung, die von Dateigröße und Verbindungsgeschwindigkeit abhängt. Eine 200-MB-Datei über eine langsame Verbindung braucht lange zum Hochladen; ein clientseitiges Tool mit derselben Datei ist nur durch die CPU deines Geräts begrenzt und startet sofort.
• Funktioniert offline. Nachdem die Seite einmal geladen wurde (und bei einer PWA von einem Service Worker zwischengespeichert wurde), funktioniert das Tool ohne jede Internetverbindung weiter — weil es nie eine brauchte, um die Arbeit zu erledigen.

Wie du es selbst überprüfst

Du musst eine Datenschutz-Behauptung nicht einfach glauben:

1. Öffne DevTools → Netzwerk-Tab, bevor du das Tool ausführst, dann verarbeite eine Datei. Achte auf jede Anfrage, deren Nutzlastgröße mit deiner Dateigröße mitwächst. Erscheint nichts dergleichen, hat die Datei den Browser nicht verlassen.
2. Trenne die Internetverbindung, dann versuche das Tool erneut (nachdem die Seite selbst geladen wurde). Funktioniert es weiterhin, ist kein Server im Spiel.
3. Prüfe das Seitengewicht, nicht nur die Behauptung. Ein Tool, das echte Arbeit lokal erledigt, lädt eine WASM-Engine — oft einen träge geladenen Chunk von mehreren hundert KB bis wenigen MB beim ersten Gebrauch dieses bestimmten Tools — statt eines kleinen Skripts, das nur ein Formular abschickt.

Genau so ist HivePDF gebaut: Jedes Tool — zusammenführen, komprimieren, schützen, schwärzen, unterschreiben und der Rest — läuft über eine aufgabenspezifische WASM-Engine in einem Web Worker, ohne Upload-Endpunkt dahinter. Für einen tieferen Blick darauf, was das in der Praxis bedeutet, sieh dir sind Online-PDF-Tools sicher und den ehrlichen Architekturvergleich mit serverbasierten Tools an.