Wie browserbasierte PDF-Bearbeitung funktioniert (und warum Datenschutz wichtig ist)

Jedes Mal, wenn Sie ein Dokument in ein Cloud-basiertes PDF-Tool hochladen, befindet sich dieses Dokument auf Servern, die Sie nicht kontrollieren, wird von Software verarbeitet, die Sie nicht überprüfen können, und von einem Unternehmen mit eigenen Datenschutz- und Sicherheitsvorkehrungen gespeichert. Für kurze Zeit befinden sich Ihre Verträge, Steuererklärungen, Krankenakten oder vertraulichen Geschäftsdokumente in der Infrastruktur eines anderen.

LuraPDF funktioniert anders. Alles findet im Browser-Tab, auf Ihrer Hardware und mit der Speicherverwaltung Ihres Betriebssystems statt. Dieser Artikel erläutert die technische Architektur, die dies ermöglicht, und die damit verbundenen technischen Kompromisse.

Der Browser als Dokumentenverarbeitungsplattform

Moderne Browser sind nicht mehr nur HTML-Renderer. Sie sind vollständige Anwendungsausführungsumgebungen mit folgenden Funktionen:

• JavaScript-Engine (V8 in Chrome, SpiderMonkey in Firefox): führt Code nahezu in nativer Geschwindigkeit aus
• WebAssembly (WASM): Führt kompilierten C/C++-Code in einer Sandbox-Umgebung nahezu in nativer Geschwindigkeit aus.
• Canvas-API: ermöglicht die Bildmanipulation auf Pixelebene
• Dateisystemzugriffs-API: Ermöglicht das Lesen lokaler Dateien ohne Hochladen
• Web Workers: Führen Berechnungen in Hintergrundthreads aus, ohne die Benutzeroberfläche einzufrieren.
• ArrayBuffer / Blob: Verwaltet rohe Binärdaten (wie PDF-Bytes) im Speicher

Zusammen ermöglichen diese Funktionen eine vollwertige Dokumentenverarbeitungspipeline, für die vor fünf Jahren noch ein Backend-Server erforderlich gewesen wäre.

Die drei Kernbibliotheken

LuraPDF basiert auf drei grundlegenden Open-Source-Bibliotheken:

pdf-lib

pdf-lib ist eine TypeScript-Bibliothek zum Erstellen und Bearbeiten von PDF-Dokumenten in jeder JavaScript-Umgebung. Sie implementiert einen wesentlichen Teil der PDF-Spezifikation (ISO 32000), darunter:

• Seitenerstellung, -änderung und -löschung
• Einbettung von Schriftarten (sowohl Standard-14-Schriftarten als auch benutzerdefinierte TTF/OTF-Schriftarten)
• Bildeinbettung (JPEG, PNG)
• Platzierung von Textanmerkungen
• Erstellung und Bearbeitung von Formularfeldern
• Dokumentmetadaten (Titel, Autor, Erstellungsdatum usw.).
• PDF-Verschlüsselung (AES-128 und AES-256)
• Verwaltung von Querverweistabellen

Beim Zusammenführen von PDFs verwendet LuraPDF pdf-lib, um die Seitenstruktur jedes Dokuments zu lesen, gemeinsam genutzte Ressourcen zu normalisieren und ein neues PDF zu erstellen. Beim Komprimieren werden Bildobjekte mit niedrigeren Qualitätsfaktoren neu kodiert. Bei der Verschlüsselung wird AES-256 mithilfe der Web Crypto API angewendet.

pdf-lib arbeitet ausschließlich mit ArrayBuffer-Objekten – also mit rohen Binärdaten im Browserspeicher. Es werden keine Netzwerkaufrufe getätigt.

pdfjs-dist

PDF.js (https://mozilla.github.io/pdf.js/) ist Mozillas PDF-Rendering-Engine und wird als pdfjs-dist auf npm vertrieben. Sie ist die Grundlage für den in Firefox integrierten PDF-Viewer und wurde anhand von Millionen realer PDFs getestet.

LuraPDF verwendet pdfjs-dist für:

• Seitenrendering: Konvertierung von PDF-Seiten in Canvas ImageData zur Anzeige
• Textextraktion: Lesen der Textinhaltsströme aus PDF-Seiten
• Seitenmetadaten: Abrufen von Seitenabmessungen, Rotationswerten und Inhaltstyp

Wenn Sie Ihre PDF-Datei in der LuraPDF-Oberfläche sehen – der visuellen Vorschau der Seiten –, dann rendert pdfjs-dist jede Seite auf ein HTML Canvas-Element.

Tesseract.js

Tesseract.js ist die mit WebAssembly kompilierte Version von Tesseract OCR. Tesseract ist eine Open-Source-OCR-Engine, die ursprünglich von HP Labs (1985) entwickelt und aktuell von Google weiterentwickelt wurde. Sie verwendet ein LSTM-Netzwerk (Long Short-Term Memory) zur Zeichenerkennung.

Tesseract über WebAssembly im Browser auszuführen bedeutet:

Die 22 MB große WASM-Binärdatei wird einmalig geladen und vom Browser zwischengespeichert. Die OCR-Verarbeitung läuft auf der CPU über WebAssembly, nicht auf der GPU. Die Verarbeitung ist langsamer als bei Cloud-OCR (die GPU-Cluster nutzt), liefert aber die gleiche Ausgabequalität. Ihre Dokumentinhalte verlassen niemals Ihr Gerät.

Für einen Scan von 20 Seiten benötigt die Browser-OCR etwa 30–120 Sekunden. Ein Cloud-Dienst hingegen nur 2–5 Sekunden. Hierbei muss man zwischen Datenschutz und Geschwindigkeit abwägen.

Die Architektur: Von der Datei zur Ausgabe

So funktioniert es beispielsweise, wenn Sie eine PDF-Datei in LuraPDF komprimieren:

1. Dateiauswahl: Sie ziehen eine PDF-Datei in den Ablagebereich. Die Datei-API des Browsers liest die Datei in einen ArrayBuffer ein – rohe Bytes im Browserspeicher. Es findet kein Upload statt.

2. Validierung: Eine kurze Überprüfung, ob die magischen Bytes %PDF am Anfang des ArrayBuffer erscheinen.

3. Ladevorgang: pdf-lib's PDFDocument.load() analysiert die Querverweistabelle, liest den Objektbaum und erstellt eine In-Memory-Repräsentation des Dokuments.

4. Bildaufzählung: Die Bibliothek durchsucht die Inhaltsströme der Seite, um Bild-XObjects (eingebettete Bilder) zu finden. Breite, Höhe, Komprimierungstyp und Byte-Daten jedes Bildes werden extrahiert.

5. Neukodierung: Die Rohpixeldaten jedes Bildes werden auf ein HTML-Canvas-Element gezeichnet und anschließend mit einem niedrigeren JPEG-Qualitätsfaktor unter Verwendung von canvas.toBlob('image/jpeg', quality) neu exportiert. Das ursprüngliche Bildobjekt wird durch die kleinere, kodierte Version ersetzt.

6. Dokumentserialisierung: Die Methoden save() der pdf-lib serialisieren das geänderte Dokument zurück in Bytes. Objektströme werden DEFLATE-komprimiert.

7. Download: Die Bytes werden in ein Blob-Objekt verpackt, eine temporäre Objekt-URL wird erstellt ( URL.createObjectURL(blob) ), und ein programmatischer Klick auf <a> löst den Download-Mechanismus des Browsers aus.

Insgesamt wurden null Bytes an einen externen Server übertragen.

Web Workers: Die Benutzeroberfläche reaktionsfähig halten

Die PDF-Verarbeitung ist rechenintensiv. Würde sie im Haupt-JavaScript-Thread ausgeführt, würde der Browser-Tab einfrieren – man könnte weder scrollen, klicken noch Fortschrittsanzeigen sehen, während die Datei verarbeitet wird.

LuraPDF führt alle rechenintensiven Prozesse (OCR, Parsen großer PDFs, Bild-Neukodierung) in Web Workern aus – separaten JavaScript-Threads, die im Hintergrund laufen. Der Hauptthread ist für die Benutzeroberfläche zuständig, zeigt Fortschrittsbalken an und kommuniziert über Nachrichtenaustausch (postMessage / onmessage) mit den Workern.

Während der OCR-Verarbeitung wird nach jeder verarbeiteten Seite ein Fortschrittsereignis ausgelöst. Der Worker sendet { page: 5, total: 20, confidence: 94 } an den Hauptthread, der die Fortschrittsanzeige aktualisiert. Ihre Benutzeroberfläche bleibt dabei interaktiv.

Speicherverwaltung

Der Browserspeicher ist begrenzt. Das Laden, Verarbeiten und Speichern einer 200 MB großen PDF-Datei kann 400–600 MB RAM benötigen (Originaldaten + zwischengespeicherte Canvas-Daten + Ausgabedaten). Auf Systemen mit begrenztem Arbeitsspeicher kann dies zu Speicherengpässen führen.

Angewandte Strategien:

• Streaming-Seitenverarbeitung: Bei mehrseitigen Operationen werden die Seiten verarbeitet und die zwischenzeitlichen Canvas-Elemente nach Gebrauch verworfen.
• URL.revokeObjectURL(): Temporäre Blob-URLs werden nach dem Download widerrufen, um die Garbage Collection zu ermöglichen.
• Beendigung der Worker: Web Worker werden nach Abschluss ihrer Aufgabe beendet, um den von ihnen verwendeten Speicher freizugeben.

Sehr große Dateien (>100 MB) können moderne Browser auf Systemen mit mindestens 8 GB RAM problemlos verarbeiten. Ältere Systeme oder Systeme mit begrenztem Arbeitsspeicher können jedoch Probleme mit Quelldateien über 100 MB haben.

Die Datenschutzarchitektur

Das Sicherheitsmodell wird durch die Same-Origin-Policy und die Isolationsarchitektur des Browsers durchgesetzt:

• Keine HTTP-Anfragen: Keine externen API-Aufrufe, keine Telemetrie, keine Analyseaufrufe während der Dokumentenverarbeitung
• Ausführung in einer Sandbox: Web Worker können keine Netzwerkaufrufe an externe Ursprünge durchführen.
• Keine dauerhafte Speicherung: Verarbeitete Dateien werden nicht im Browserspeicher (localStorage, IndexedDB oder Dateisystemzugriff) gespeichert. Tab-bezogener Speicher: Beim Schließen des Tabs werden alle zugehörigen ArrayBuffers- und Blob-Objekte vom Garbage Collector freigegeben.

Diese Architektur lässt sich überprüfen: Öffnen Sie während der Dateiverarbeitung den Netzwerk-Tab in den Entwicklertools Ihres Browsers. Sie werden während des Verarbeitungsvorgangs keine Anfragen sehen.

Open-Source-Bibliotheken: Überprüfbar, keine Blackbox

Alle drei Kernbibliotheken – pdf-lib, pdfjs-dist und Tesseract.js – sind Open Source und auf GitHub öffentlich zugänglich. Die Implementierungen sind für jeden einsehbar. Der in LuraPDF verwendete PDF-Verarbeitungscode ist keine proprietäre Blackbox, sondern öffentlicher Code mit echten Nutzern, Problemen und Beiträgen.

Das ist wichtig für das Vertrauen. Wenn ein Cloud-Dienst sagt: „Wir verarbeiten und löschen Ihre Dateien“, müssen Sie sich auf sein Wort verlassen. Wenn LuraPDF Open-Source-Bibliotheken in einer Browser-Sandbox ohne Netzwerkzugriffe verwendet, können Sie die Aussage überprüfen, indem Sie den Netzwerk-Tab beobachten.

Abwägungen gegenüber Cloud-Verarbeitung

Das browserbasierte Modell hat echte Kompromisse, über die man ehrlich sprechen sollte:

Geschwindigkeit: Cloud-Dienste verfügen über GPU-Cluster und dedizierte Infrastruktur. Die Browser-OCR benötigt bei großen Dokumenten 2- bis 10-mal länger als eine vergleichbare Cloud-Lösung. Die Komprimierung ist schnell, da die Canvas-API direkt genutzt wird.

Dateigrößenbeschränkungen: Der Browserspeicher ist die limitierende Größe. Sehr große Dateien (>300 MB) können auf manchen Systemen an die Speichergrenzen stoßen. Cloud-Dienste unterliegen keiner solchen Beschränkung.

Verarbeitungsleistung: WASM erreicht 40–80 % der Geschwindigkeit von nativem C++. Cloud-Dienste nutzen optimierten nativen Code. Bei den meisten Dokumenten ist dieser Unterschied nicht wahrnehmbar; bei OCR-Aufträgen mit mehr als 100 Seiten ist er jedoch deutlich spürbar.

Funktionen: Einige erweiterte PDF-Funktionen (PDF/X-Konformitätsprüfung, professionelles Farbmanagement, CMYK-Workflows) erfordern spezielle serverseitige Tools. Die browserbasierte Verarbeitung deckt 95 % der Fälle ab.

Für die alltägliche Dokumentenverarbeitung – Komprimieren, Zusammenführen, Signieren, Konvertieren, Schwärzen – ist das browserbasierte Modell schnell genug, von Grund auf datenschutzfreundlich und erfordert weder ein Konto noch ein Abonnement.

Häufig gestellte Fragen

Erfasst LuraPDF Telemetrie- oder Nutzungsdaten? LuraPDF verwendet Google Analytics für aggregierte Seitenaufrufstatistiken. Die Dokumentenverarbeitung generiert keine Analysedaten. Der Inhalt Ihrer Dateien wird niemals übertragen.

Kann ich bestätigen, dass kein Upload stattfindet? Ja. Öffnen Sie die Entwicklertools (F12), klicken Sie auf den Tab „Netzwerk“ und filtern Sie nach „XHR“ oder „Abruf“. Verarbeiten Sie eine Datei. Beobachten Sie, dass während der Verarbeitung keine dokumentbezogenen Netzwerkanfragen gestellt werden.

Warum dauert die OCR-Verarbeitung im Vergleich zu anderen Diensten so lange? Das browserbasierte Tesseract.js läuft über WebAssembly auf der CPU. Cloud-OCR-Dienste hingegen nutzen GPU-Cluster, die Zeichen um ein Vielfaches schneller verarbeiten. Der Nachteil: Ihr Dokument verlässt nie den Browser.

Was passiert, wenn ich den Tab während der Verarbeitung schließe? Die Verarbeitung wird sofort beendet. Der Speicher des Browser-Tabs wird freigegeben. Ihre Originaldatei auf der Festplatte bleibt unverändert.

Ist der Code Open Source? Die zentralen Verarbeitungsbibliotheken (pdf-lib, pdfjs-dist, Tesseract.js) sind Open Source. Der Schnittstellencode von LuraPDF ist derzeit nicht Open Source, die Verarbeitungspipeline verwendet jedoch ausschließlich Open-Source-Komponenten.

Die Umstellung auf browserbasierte Dokumentenverarbeitung ist kein bloßer Marketingtrick. Sie ist eine bewusste architektonische Entscheidung mit messbaren Vorteilen in puncto Datenschutz und Vertrauen – allerdings auf Kosten der Geschwindigkeit bei rechenintensiven Operationen. Für Dokumente, die Sie lieber nicht auf einem fremden Server speichern möchten, ist dies der richtige Kompromiss.