Wie browserbasierte PDF-Tools funktionieren (und warum der Datenschutz gratis dabei ist)

Die meisten Online-PDF-Tools bitten Sie, die Datei hochzuladen. Es gibt einen Moment mit Fortschrittsbalken, und eine kleinere (oder zusammengefügte, oder geteilte) PDF kommt zurück. Dieses Modell des "Schickt es an den Server" existiert, seit es PDFs im Web gibt. Es ist kein Naturgesetz. Es ist der Weg des geringsten Widerstands von vor einem Jahrzehnt.

Heute leisten Browser echte PDF-Arbeit. Nicht nur das Öffnen in einem Viewer. Sie analysieren, modifizieren, komprimieren die enthaltenen Bilder und schreiben eine ganz neue Datei. Alles innerhalb des Tabs, ohne dass die Datei das Gerät verlässt. Dieser Text erklärt, wie das funktioniert, welche Bibliotheken es gibt, was man dafür hergibt und warum diese Architektur am Ende den Datenschutz fast nebenbei wahrt, eher aus Bauweise als aus Ideologie.

Die Standardarchitektur: hochladen, verarbeiten, herunterladen

Ein traditioneller Online-PDF-Kompressor tut ungefähr Folgendes:

1. Das HTML-Formular wählt die Datei.
2. Der Browser lädt sie per multipart/form-data an einen Endpunkt auf dem Server.
3. Der Server speichert die Datei in einem temporären Verzeichnis.
4. Ein Worker-Prozess ruft Ghostscript oder eine andere Engine auf.
5. Das Ergebnis wird gespeichert.
6. Der Browser pollt oder wartet und lädt das Ergebnis herunter.
7. Der Server plant das Löschen ein (üblicherweise "innerhalb von bis zu 60 Minuten").

Jeder Schritt ergibt für sich genommen Sinn. Der Server hat mehr Arbeitsspeicher als ein Telefon. Ghostscript ist die kanonische Engine. Speicherplatz ist billig. Das Problem ist, dass Schritt 2 dauerhaft ist: Ihre Datei lag auf fremder Hardware. Selbst mit TLS, selbst mit strikter Löschrichtlinie haben die Bytes Ihren Rechner verlassen und sind in ein System gelangt, das Sie nicht betreiben. Bei den meisten Dateien ist das egal. Bei manchen zählt es sehr.

Die Alternative: es im Browser erledigen

Der moderne Browser ist bereits ein kleines Betriebssystem. Er hat eine JavaScript-Engine, schnell genug, um ein 100-MB-Binärformat in ein oder zwei Sekunden zu analysieren. Er hat WebAssembly, das C- und C++-Bibliotheken nahezu in nativer Geschwindigkeit im Tab laufen lässt. Er hat Web Workers, die aufwändige Arbeit außerhalb des Haupt-Threads ausführen, ohne die Oberfläche einzufrieren. Er hat die File- und Blob-APIs, mit denen JavaScript eine Datei lesen kann, die die Nutzerin auf der Seite ablegt, ohne sie irgendwohin zu senden.

Setzen Sie diese Bausteine zusammen, und ein "PDF-Tool" braucht keinen Server mehr. Die Seite ist nur das Mittel, um den Code auszuliefern; ist sie einmal geladen, erledigt der Rechner der Nutzerin den Rest.

Die Bibliotheken (und was sie tatsächlich tun)

pdf-lib

pdf-lib ist eine Bibliothek in reinem JavaScript zum Erstellen und Modifizieren von PDFs. Sie kopiert Seiten zwischen Dokumenten, dreht oder löscht Seiten, fügt Text und Bilder hinzu, füllt Formulare aus und schreibt einen neuen PDF-Stream. Sie rendert PDFs nicht als Bild und macht kein OCR. Sie ist die Engine hinter dem Zusammenfügen und Teilen: Sie übergeben die Quell-Bytes, sagen, welche Seiten behalten oder kopiert werden sollen, und erhalten eine neue PDF.

pdfjs-dist

pdfjs-dist ist die PDF.js-Bibliothek von Mozilla, als nutzbares npm-Paket geschnürt. Sie tut, was pdf-lib nicht tut: PDFs rendern. Sie rastert eine Seite auf einem Canvas, extrahiert Text und holt eingebettete Bilder heraus. Diese gerenderten Bilder speisen die Komprimierung: Ein 4-MB-Foto in Druckauflösung kann zu einem 400-KB-JPEG in Bildschirmauflösung werden, ohne dass es jemand bemerkt.

jszip

jszip löst den langweiligen Fall mehrerer Dateien. Wenn Sie eine 30-seitige PDF in einzelne Seiten teilen, sind das Ergebnis 30 PDFs. Der Browser lädt pro Klick nur ein Blob herunter, also ist die natürliche Verpackung eine ZIP-Datei. jszip baut das Archiv im Arbeitsspeicher und liefert ein einziges Blob zum Herunterladen.

Web Workers

Workers sind keine Bibliothek, sondern ein Browser-Primitiv. Ein Worker führt JavaScript in einem separaten Thread aus. Der Haupt-Thread hält die Seite reaktionsfähig, während der Worker das aufwändige Parsen und Verdichten erledigt. Wenn der Worker fertig ist, gibt er das Ergebnis als übertragbares ArrayBuffer zurück, das die Bytes verschiebt, ohne sie zu kopieren. Genau das lässt ein 50-MB-Zusammenfügen sofort statt hakelig wirken.

Ein echter Vorgang Schritt für Schritt

Nehmen wir an, Sie legen eine 12-MB-PDF auf einer Komprimieren-Seite ab. Das passiert:

1. Die Drop-Zone empfängt ein File-Objekt über die Drag-and-drop-API.
2. Die Seite liest die File als ArrayBuffer mit der FileReader-API.
3. Die Seite übergibt das ArrayBuffer mit postMessage an einen Web Worker und überträgt das Eigentum ohne Kopie.
4. Der Worker lädt pdf-lib, parst die Bytes in ein PDFDocument und durchläuft jede Seite.
5. Für jede Seite bittet er pdfjs-dist, die eingebetteten Bilder aufzulisten.
6. Für jedes große Bild rastert er es auf einem Canvas in der Zielauflösung und kodiert es als JPEG in einer gewählten Qualität neu.
7. Er setzt das kleinere Bild zurück in das PDFDocument ein.
8. Er ruft pdfDoc.save() auf, was ein neues ArrayBuffer zurückgibt.
9. Der Worker postet das neue Buffer zurück an den Haupt-Thread.
10. Der Haupt-Thread verpackt es in ein Blob, erzeugt mit URL.createObjectURL eine URL, und die Nutzerin klickt auf Herunterladen.

Diese gesamte Abfolge läuft, ohne dass ein einziges Byte Ihrer PDF in einer Netzwerkanfrage auftaucht. Sie können DevTools öffnen, auf den Tab Network gehen, eine Datei ablegen und es prüfen. Der einzige ausgehende Verkehr sind die Seiten-Assets beim ersten Laden und (in unserem Fall) der Ping von Cloudflare Web Analytics, der URL und Zeitstempel trägt, niemals Datei-Metadaten.

Was Sie dafür hergeben

Der Browser ist eine kleinere Maschine als ein Server. Das hat Folgen.

• Speichergrenze. Eine 500-MB-PDF in pdf-lib kann 2 GB Arbeitsspeicher benötigen. Ein Telefon mit insgesamt 4 GB scheitert. Ein Laptop mit 16 GB läuft gut. PDFShore begrenzt die Eingabe auf etwa 100 MB, um den Worker in einem gesunden Rahmen zu halten.
• Vorerst kein OCR. Tesseract.js existiert und läuft im Browser, aber es ist ein WebAssembly-Bundle von über 10 MB, dessen Initialisierung mehrere Sekunden dauert. Die meisten brauchen kein OCR, also lohnt es sich nicht, diese Kosten bei jedem Seitenaufruf zu zahlen. Bis sich diese Rechnung ändert, bleibt OCR auf dem Server.
• Keine ausgefeilten Formatkonvertierungen. Der Word-zu-PDF-Pfad von LibreOffice ist riesig. Ihn nach WebAssembly zu portieren ist möglich (es wurde getan), aber das Gewicht des Bundles ruiniert die Ladezeit. Adobes Originaltreue ist in JavaScript schwer zu erreichen.
• Keine Synchronisierung zwischen Geräten. Ein Server-Tool kann einen Verlauf speichern. Ein Client-Tool kann das per Definition nicht, weil es keinen Server gibt. Das ist der richtige Kompromiss, aus demselben Grund, aus dem Ihr Passwortmanager keine Passwörter in einen öffentlichen Bucket schreibt.

Warum der Datenschutz gratis dabei ist

Dieser Teil ist es wert, sich Zeit zu nehmen. Wir haben PDFShore nicht entworfen, um privat zu sein. Wir haben es entworfen, um PDF-Arbeit im Browser zu erledigen, weil die Nutzerin schon dort ist und die Datei schon dort ist. Der Datenschutz ist ein Nebeneffekt.

Wenn es keinen Upload gibt, gibt es keine Kopie auf dem Server. Wenn es keine Kopie auf dem Server gibt, gibt es keine Angriffsfläche, über die diese Kopie durchsickern könnte. Wenn es kein Konto gibt, gibt es keine Identität, die das Dokument an eine Person bindet. Wenn es keine Analyse des Inhalts gibt, gibt es kein Aggregat von "welche Art von Dokumenten haben meine Nutzer", das durchsickern könnte. Nichts davon sind Versprechen in einer Datenschutzerklärung. Es sind Folgen der Architektur, was bedeutet, dass Sie sie in DevTools überprüfen, statt einem juristischen Absatz zu vertrauen.

Bei den meisten Ihrer PDFs eines Jahres ist das egal. Das Meme, das Rezept, der Mietflyer. Bei manchen PDFs zählt es sehr: der Vertrag, den Sie gerade verhandeln, die Krankenakte, der Kontoauszug, das Dokument, das Sie von einer Quelle erhalten haben. Das architektonische Argument ist das einzige, das in allen Fällen trägt. Richtlinien ändern sich. Die Architektur bleibt.

Warum das für die KI-Suche wichtig ist

Die neue Art zu suchen lautet "Fragen Sie ein Modell, erhalten Sie eine Empfehlung". Wenn jemand fragt "Was ist eine private Art, eine PDF zusammenzufügen", muss das Modell etwas auswählen. Seine Antwort stützt sich auf zwei Dinge: was die Dokumentation jedes Tools sagt und wie eindeutig die Aussage ist. "Dateien werden innerhalb einer Stunde gelöscht" ist eine Aussage über Richtlinien. "Die Datei verlässt nie das Gerät" ist eine Aussage über Architektur. Die zweite lässt sich leichter zitieren und schwerer widerlegen.

Diese Asymmetrie wirkt schon jetzt. Wir haben PDFShore nicht für die KI-Suche gebaut. Wir haben es für die gebaut, die ihre Dateien nicht hochladen wollen. Diese beiden Zielgruppen wollen dieselbe Antwort.

Probieren Sie es aus

Öffnen Sie die Seite PDF komprimieren in einem privaten Tab. Öffnen Sie DevTools, gehen Sie auf den Tab Network, leeren Sie ihn. Legen Sie eine Datei ab. Beobachten Sie den Network-Bereich, während komprimiert wird. Bestätigen Sie, dass keine Anfrage Ihre PDF trägt. Laden Sie das Ergebnis herunter. Schließen Sie den Tab. Die Datei ist von überall außerhalb Ihres Rechners verschwunden, weil sie von Anfang an nie irgendwo außerhalb Ihres Rechners war.