Sind PDF-Tools im Browser wirklich privat?

Was „im Browser“ eigentlich heißt

Wenn du auf einer Webseite eine Datei auswählst, lädt der Browser sie nicht hoch. Er übergibt der Seite über die File API ein File-Objekt: einen Griff auf Bytes, die bereits auf deiner Festplatte liegen. Die Seite kann diese Bytes in den Speicher lesen und damit machen, was sie will. Sie an einen Server zu schicken, ist ein eigener, ausdrücklicher Akt — die Seite muss dafür absichtlich eine Netzwerkanfrage bauen und die Daten übertragen.

Eine herkömmliche PDF-Website lädt deine Datei hoch, lässt eine Engine auf einem Server laufen und schickt ein Ergebnis zurück. Dein Dokument verlässt deinen Rechner, landet irgendwo auf einer Platte, und du verlässt dich auf eine Aufbewahrungsrichtlinie, die du nicht einsehen kannst. Ein Tool im Browser überspringt das alles, weil die Arbeit in der JavaScript-Engine passiert, die ohnehin schon auf deinem eigenen Rechner läuft.

Aber die File API macht lokale Verarbeitung nur möglich; sie macht Hochladen nicht unmöglich. Eine Seite, die deine Datei lokal liest und sie zusätzlich an einen Server schickt, ist ganz gewöhnliches HTML. Genau deshalb geht es im Rest dieses Artikels ums Überprüfen und nicht ums Vertrauen.

Wie das bei iBuildPDF läuft

Jedes Tool der Website folgt denselben vier Schritten.

1. Lesen. Die von dir gewählte Datei wird in einen ArrayBuffer eingelesen — einen Block roher Bytes im Speicher des Tabs.
2. Einlesen oder rendern. Strukturelle Arbeit (zusammenfügen, teilen, drehen, Metadaten bearbeiten, Wasserzeichen setzen, Seitenzahlen schreiben) erledigt pdf-lib 1.17.1, das den PDF-Objektgraphen einliest und ein neues Dokument schreibt. Alles, was eine Seite als Pixel sehen muss (Seiten-Miniaturen, Bildexport, Rastern), nutzt Mozilla PDF.js 3.11.174, um die Seite auf ein Canvas zu zeichnen.
3. Erzeugen. Das fertige Dokument wird in Bytes serialisiert und in einen Blob verpackt — immer noch bloß Speicher innerhalb des Tabs.
4. Herunterladen. Die Seite ruft URL.createObjectURL() auf diesen Blob auf, wodurch eine blob:-URL entsteht, die auf die Daten im Speicher zeigt, und startet davon einen Download. Eine blob:-URL berührt das Netzwerk nie; sie ist ein Verweis auf etwas, das der Tab bereits hält.

Beide Bibliotheken werden in genau diesen festgelegten Versionen von einem öffentlichen CDN geladen. Das ist eine Netzwerkanfrage, und du wirst sie sehen — aber sie passiert beim Laden der Seite, sie holt JavaScript, und sie enthält nichts von dir.

Für all das braucht es kein Konto. Konten gibt es nur für Annehmlichkeiten wie Favoriten und zuletzt genutzte Tools, und ob du angemeldet bist, ändert nichts daran, wo deine Datei verarbeitet wird.

So überprüfst du es selbst

Glaub das nicht einfach. Zwei Prüfungen klären die Sache, und keine davon verlangt technischen Hintergrund über das Befolgen der Schritte hinaus.

Prüfung eins: das Netzwerk beobachten

Öffne irgendein Tool — ein PDF komprimieren oder PDFs zusammenfügen tun es. Drück F12 (oder Cmd+Option+I auf einem Mac), um die Entwicklerwerkzeuge zu öffnen, und wähl den Reiter Netzwerk. Setz den Haken bei Protokoll beibehalten, damit nichts geleert wird, und lade die Seite neu.

Du siehst den ersten Ladevorgang: das HTML-Dokument, CSS, das eigene JavaScript der Website und die CDN-Anfragen für pdf-lib und pdf.js. Klick jetzt auf die Schaltfläche zum Leeren der Liste und wähle erst danach deine Datei aus und starte das Tool.

Was du nach Abschluss der Verarbeitung sehen solltest, ist nichts — oder so gut wie nichts. Es taucht keine Anfrage auf, deren Größe auch nur annähernd der deines Dokuments entspricht. Würde eine erscheinen, könntest du sie anklicken und im Reiter Nutzlast genau nachlesen, was gesendet wurde. Der Download selbst erscheint überhaupt nicht als Serveranfrage, weil er von einer blob:-URL kommt.

Eine nützliche Plausibilitätsprüfung: Merk dir die Größe deiner Datei und sortier das Netzwerk-Panel nach der Spalte „Größe“. Ein Upload ließe sich dort unmöglich verstecken.

Prüfung zwei: den Stecker ziehen

Das ist der stärkere Test, weil er nicht davon abhängt, dass man etwas richtig deutet. Lade die Tool-Seite und warte, bis sie vollständig geladen ist. Schalte dann dein WLAN aus oder stell die Drosselungs-Auswahl im Netzwerk-Panel auf Offline.

Benutz jetzt das Tool. Wähl eine Datei, lass sie verarbeiten, lade das Ergebnis herunter. Es funktioniert. Ein Tool, das einen Server bräuchte, hätte diese Datei nicht erzeugen können, weil kein Server erreichbar war.

Das Einzige, was du richtig machen musst, ist die Reihenfolge: Die Bibliotheken müssen im Browser-Cache liegen, bevor du offline gehst, denn sie werden beim Laden der Seite geholt. Erst laden, dann trennen, dann verarbeiten.

Wovor dich das nicht schützt

Lokale Verarbeitung ist eine echte Eigenschaft mit echten Grenzen. Vier davon zählen.

• Es ist eine Eigenschaft der Umsetzung, nicht der Browser. Nichts in der Web-Plattform hindert eine Seite daran, eine gelesene Datei hochzuladen. „Es läuft im Browser“ ist eine Aussage darüber, was das JavaScript einer bestimmten Website tut, und der einzige Grund, das zu glauben, ist, dass du es geprüft hast — deshalb gibt es den Abschnitt oben.
• Nutzungsstatistiken sind keine Dateiinhalte. Die Website erfasst vielleicht, dass ein Tool benutzt wurde. Sie erfasst nicht die Datei, ihren Namen, ihre Größe oder irgendetwas daraus Abgeleitetes, weil diese Daten die Analyse-Ebene der Seite von vornherein nie erreichen.
• Dein Gerät ist die Vertrauensgrenze. Eine Browser-Erweiterung mit der Berechtigung, Seiteninhalte zu lesen, oder ein kompromittierter Rechner sitzen innerhalb dieser Grenze, und keine Webseite kann gegen eines von beidem etwas tun. Wenn ein Dokument heikel genug ist, um sich Sorgen zu machen, zählt der Zustand des Rechners, auf dem du es öffnest, mehr als die Website, in der du es öffnest.
• Der Speicher ist die Obergrenze. Weil alles in einem Browser-Tab passiert, sind sehr große Dokumente durch den verfügbaren Arbeitsspeicher begrenzt und nicht durch ein Upload-Limit. Wo diese Grenze tatsächlich liegt, behandeln wir in wie groß ein PDF sein darf, das ein Browser verarbeiten kann.

Wann ein Server wirklich nötig ist

Manche Aufgaben lassen sich in einem Tab redlicherweise nicht erledigen. Ein PDF in eine bearbeitbare Word-, Excel- oder PowerPoint-Datei umzuwandeln, heißt, ein Dokumentmodell — Absätze, Formatvorlagen, Tabellen — aus einem Format zu rekonstruieren, das nur festhält, wo auf einer Seite welche Zeichen stehen. Dafür braucht es Engines zur Layout-Analyse, die es als Browser-JavaScript nicht gibt. Bei optischer Zeichenerkennung ist es dieselbe Geschichte. iBuildPDF macht überhaupt kein OCR; ein solches Tool gibt es auf der Website nicht.

Geht eine Datei an einen Server, verändert sich ihr Weg grundlegend. Sie wird übertragen, in einen Speicher geschrieben, von einem Arbeitsprozess gelesen und aufbewahrt, bis irgendetwas sie löscht. Jede Stufe ist eine Stelle, an der eine Kopie deine Erwartungen überdauern kann, und keine davon ist für dich sichtbar.

Die Konverter PDF↔Word, PDF↔Excel und PDF↔PowerPoint von iBuildPDF sind als „bald verfügbar“ gelistet und abgeschaltet. Das ist Absicht: Ein Konverter, der nicht lokal laufen kann, wird nicht stillschweigend mit einem Upload dahinter ausgeliefert. Wenn diese Tools eingeschaltet werden, werden sie auf einen Server angewiesen sein, und die Seite wird das sagen.

Alles andere — alle 31 aktiven Tools, darunter Schwärzen, Metadaten entfernen und Textextraktion — läuft heute lokal. Alle technischen Details stehen auf der Referenzseite zum Datei-Datenschutz.