Warum Ihr PDF-Tool im Browser laufen sollte, nicht in der Cloud

Jede Seite nach dem Muster "Datei hineinziehen, bearbeitet zurückbekommen" macht dasselbe Angebot, und für eine Broschüre oder einen Lebenslauf ist das ein völlig gutes Angebot. Bei einem unterschriebenen Vertrag, einer Steuererklärung oder irgendetwas mit dem Namen einer Mandantin darauf ist der Upload der Teil, über den es sich nachzudenken lohnt.

Üblicherweise wird das als Cloud schlecht, Browser gut erzählt. Diese Erzählung ist bequem, und sie fällt in dem Moment auseinander, in dem Sie ein Tool um etwas bitten, das ein Browser schlicht nicht kann. Die brauchbare Frage ist enger: welche Operationen können überhaupt lokal laufen, und sagt Ihnen das Tool vor Ihnen, auf welcher Seite dieser Grenze es steht.

Unseres läuft auch nicht immer lokal. Dazu weiter unten, mit Namen.

Was ein Upload wirklich preisgibt

Das optimistische Modell lautet: Datei hoch, Server verarbeitet, Ergebnis herunter, Datei weg. Es ist an vier Stellen optimistisch.

Die Datei

Sie landet auf der Infrastruktur von jemandem, und ihr weiteres Schicksal regelt eine Richtlinie, die Sie nicht gelesen haben. Einen Tag aufbewahrt, aufbewahrt bis Sie fragen, durch eine Qualitätskontrolle mit einem Menschen darin geschickt, in ein Trainingskorpus aufgenommen. Kostenlose Angebote werden von irgendetwas subventioniert, und nicht immer von Werbung.

Die Metadaten, an die Sie nicht gedacht haben

Ein PDF trägt ein Document Information Dictionary und ein XMP-Paket, und jede Bibliothek kann beides lesen. pdf-lib legt die Felder direkt offen²: Titel, Autor, Betreff, Schlagwörter, Producer, Creator, Erstellungsdatum, Änderungsdatum.

In einer aus einem Office-Paket exportierten Datei ist "Autor" meist der Kontoname des Betriebssystems, und "Producer" nennt Software und Version. Sie können den Dokumententext sorgfältig säubern und trotzdem Ihren Namen, Ihren Arbeitgeber und die genaue Minute mitliefern.

Inhalt, den Sie für entfernt hielten

Ein gefülltes Rechteck über Text zu zeichnen entfernt den Text nicht. Es fügt eine Form hinzu, die zufällig darüber liegt, und die ursprünglichen Operatoren bleiben im Content-Stream.

Wir haben diese Datei gebaut, statt es zu behaupten: eine Seite mit einem Vergleichsbetrag, ein schwarzes Rechteck darüber, gespeichert, dann wieder geöffnet und mit PDF.js gelesen. getTextContent() gab die Zeile vollständig zurück, samt Währung.

Laden Sie so eine Datei irgendwo hoch, und der Empfänger hat die Zahl.

Die Anfrage selbst

Selbst ein Dienst, der Ihre Datei sofort wieder löscht, behält Zugriffsprotokolle: Ihre Adresse, den Zeitstempel und den Dateinamen. Heisst die Datei acme-acquisition-term-sheet-2026.pdf, war sie fast überflüssig.

Was ein Browser wirklich kann

Die alte Abwertung, PDF-Tools im Browser seien Spielzeug, stimmt seit einiger Zeit nicht mehr. Die tatsächliche Beschränkung ist konkret statt allgemein.

pdf-lib ist reines JavaScript und erledigt die strukturelle Arbeit: Teilen und Zusammenführen, Formulare ausfüllen, Schriften und Bilder einbetten, zeichnen sowie Metadaten lesen und setzen². Es schreibt ein gewöhnliches PDF, keinen speziellen Browser-Dialekt. Unser PDF-Merger und unser PDF-Splitter bauen darauf auf, und beide senden nichts irgendwohin.

PDF.js ist Mozillas Renderer, der in Firefox³. Er parst und zeichnet, was ihn zum richtigen Werkzeug für Vorschau, Textextraktion und den Export von Seiten als Bilder macht. Eine Bibliothek zum Erzeugen ist er nicht.

Und dann kommt der Teil, den fast jeder Artikel zu diesem Thema falsch hat.

Die Passwort-Grenze

pdf-lib kann nicht verschlüsseln. Die README sagt es direkt: verschlüsselte Dokumente werden derzeit nicht unterstützt, und die Option ignoreEncryption, die es zum Laden gibt, entschlüsselt nichts¹.

Dieser eine Satz entscheidet viel. Eine Webseite, die anbietet, ein PDF-Passwort zu setzen oder zu entfernen, tut eines von zwei Dingen: Sie liefert einen WebAssembly-Build einer nativen Bibliothek aus, ein grosser Download, den die Nutzerin beim ersten Laden bezahlt, oder sie lädt die Datei hoch. In der Praxis fast immer das Zweite.

Komprimierung liegt aus einem anderen Grund auf derselben Seite. Echte PDF-Komprimierung heisst, die eingebetteten Bilder neu zu kodieren und die Objekttabelle neu zu bauen, das ist eine Bild-Pipeline und kein Seiten-Umschreiber. WebAssembly-Builds von Ghostscript oder MuPDF können das im Tab, zum Preis eines Bundles in Megabyte-Grösse, und Ghostscripts AGPL-Lizenz ist ein eigenes Gespräch, bevor Sie das ausliefern.

Unsere eigenen Tools, weil alles andere seltsam wäre

Manche Tools auf dieser Seite laufen in Ihrem Browser. Manche nicht, und in einem Artikel über PDF-Datenschutz etwas anderes zu behaupten wäre schlimmer, als gar nichts zu sagen.

Im Tab, nichts wird hochgeladen: PDF-Merger , PDF-Splitter , PDF-Seiten drehen , PDF-Seiten sortieren , Bild zu PDF , PDF zu Text , PDF zu Bild .

Auf unsere Server in der EU geladen, verarbeitet, nach 15 Minuten gelöscht: PDF-Kompressor , PDF mit Passwort schützen , PDF entsperren sowie die ausdrücklich als "Server-Side" benannten Varianten von Merge, Split und Rotate, die es für Dateien gibt, an denen die Browser-Versionen scheitern.

Jedes dieser Tools sagt auf seiner eigenen Seite, was es ist, und die Server-Varianten tragen es im Namen. Ist ein Dokument sensibel genug, dass dieser Artikel darauf zutrifft, nehmen Sie eines aus der ersten Liste oder eine Desktop-Anwendung.

Was Browser weiterhin schlecht können

OCR. Aus einem Scan durchsuchbaren Text zu machen braucht ein trainiertes Modell. OCR im Browser gibt es und sie läuft, und bei einem langen Dokument ist sie langsam und das Ergebnis muss nachkorrigiert werden. Wer Qualität braucht, braucht ein Backend, und dann lautet die Frage, welchem Backend man vertraut, nicht ob man eines nimmt.

Signaturprüfung. Eine Signatur zu prüfen heisst, eine Zertifikatskette abzulaufen und den Sperrstatus abzufragen, beides sind Netzwerkaufrufe. Das ist keine Browser-Beschränkung, sondern das Wesen der Prüfung.

Bevor Sie irgendetwas hochladen

Die ganze Checkliste fällt auf eine Frage und einen Test zusammen.

Die Frage: Enthält diese Datei den Namen einer realen Person, Geld, juristische Bedingungen, Gesundheitsdaten oder irgendetwas, das Ihr Arbeitgeber vertraulich nennen würde? Dazu: Gibt es Metadaten, die Sie nicht vorlesen würden, und wurde etwas "geschwärzt", indem man darüber gezeichnet hat?

Der Test, für jedes Tool einschliesslich dieses hier: DevTools öffnen, Tab Netzwerk, mit einer kleinen Datei ausführen. Ein Upload ist unverkennbar, eine Multipart-Anfrage ungefähr in der Grösse Ihres Dokuments. Nichts dergleichen heisst, die Arbeit fand lokal statt. Das dauert dreissig Sekunden und klärt die Frage, über die eine Datenschutzerklärung nur Behauptungen aufstellt.

Wenn es doch ein gehosteter Dienst sein muss: Lesen Sie die Aufbewahrungsfrist statt der Marketingseite, prüfen Sie die Jurisdiktion, und finden Sie heraus, ob je ein Mensch die Datei sieht.

Warum das strukturell ist

Ein Dienst, der Dokumente hält, und sei es für fünfzehn Minuten, ist eine Sammlung von Dokumenten. Das ist kein Vorwurf an irgendjemanden. Es ist die Architektur: eine Datenbank, die man kompromittieren kann, ein Speicher, den man falsch konfigurieren kann, Personal mit Zugriff.

Ein Tool, das Ihre Datei nie erhält, hat davon nichts, und auch keine Richtlinie, der man vertrauen müsste, weil es nichts gibt, worüber man eine Richtlinie hätte.

Das ist das ganze Argument, und deshalb muss die ehrliche Fassung die Fälle einschliessen, in denen der Browser nicht hilft. Genau zu wissen, welche vier Operationen einen Upload erzwingen, ist nützlicher als zu glauben, der Browser könne alles, und das beim Hochladen eines Vertrags herauszufinden.