Diese Seite erklärt, welche Software den PDF-zu-TXT-Schritt macht, wie PDF.js mit eingebettetem Text umgeht, wann Tesseract.js für OCR aktiviert wird und warum keine Datei den Browser verlässt. Kein Marketing-Sprech, sondern die echte Konvertierungs-Logik.

Konvertierungs-Engine: PDF.js (Mozilla)

Die Text-Extraktion aus regulären PDFs läuft über PDF.js, einen von Mozilla seit 2011 gepflegten PDF-Parser, der in Firefox als Default-Reader eingebaut ist und per pdfjs-dist als NPM-Paket ausgeliefert wird. Der eigentliche Parser läuft in einem separaten Web-Worker, damit der Main-Thread für die UI reaktiv bleibt. Der Worker wird per GlobalWorkerOptions.workerSrc registriert; pdftxt.de bundelt den Worker zusammen mit dem App-Code, damit kein zusätzlicher Netzwerk-Request bei der ersten Konvertierung nötig ist.

Der konkrete Pipeline-Aufruf sieht ungefähr so aus:

const pdfjs = await import('pdfjs-dist');
pdfjs.GlobalWorkerOptions.workerSrc = workerUrl;

const buffer = await file.arrayBuffer();
const doc = await pdfjs.getDocument({ data: new Uint8Array(buffer) }).promise;

const pages = [];
for (let i = 1; i <= doc.numPages; i++) {
  const page = await doc.getPage(i);
  const content = await page.getTextContent();
  const text = content.items.map((it) => it.str).join(' ');
  pages.push(text);
}

getTextContent() liefert pro Seite ein Array von Text-Items mit Position (transform-Matrix), Schriftname und Schrift-Höhe. Für die TXT-Ausgabe genügt das .str-Feld, die Position-Info wird nur für die Heuristik (Spalten-Erkennung in Welle 2 geplant) ausgewertet.

OCR-Engine: Tesseract.js (WebAssembly)

Wenn eine PDF gescannte Seiten enthält, liefert getTextContent() nahezu nichts: statt eingebetteter Text-Items steht im PDF nur ein Bild pro Seite. Für diese Fälle aktiviert pdftxt.de Tesseract.js, einen WebAssembly-Port der Tesseract-OCR-Engine (Google/HP-Erbe, seit 1985 als Open-Source seit 2005). Das Sprachmodell deu ist rund 10 MB gross, eng ebenfalls rund 10 MB; beide werden bei aktivierter OCR vom Tessdata-CDN (tessdata.projectnaptha.com / jsdelivr) nachgeladen und im Browser-Cache vorgehalten.

Die Singleton-Implementierung hält eine Worker-Instanz für die gesamte Session vor, damit nicht jede Seite den Worker-Startup-Overhead trifft. Performance-Erwartung: rund 2-5 Sekunden pro Standardseite auf moderner Hardware, deutlich langsamer auf Mobile. Accuracy für deutschen Standarddruck ohne Handschrift liegt erfahrungsgemäss bei 95 bis 99 Prozent, sinkt aber bei schlecht gescannten Vorlagen, exotischen Schriften oder Tabellenstruktur deutlich.

Encoding-Mathematik

Die extrahierten Text-Items kommen in JavaScript bereits als UTF-16-Strings an. Für den Download als .txt-Datei muss aber eine konkrete Byte-Kodierung gewählt werden. pdftxt.de bietet vier Optionen:

UTF-8 (Default), universelle Kodierung, alle Unicode-Zeichen darstellbar
UTF-8 mit BOM, gleich wie UTF-8, plus 3-Byte-Präfix (EF BB BF), damit Excel die Datei korrekt erkennt statt als Windows-1252 zu interpretieren
ISO-8859-1 (Latin-1), 256 Zeichen, deckt westeuropäische Sprachen ab, kein Euro-Zeichen
Windows-1252 (CP1252), Microsoft-Variante von Latin-1 mit zusätzlichen 27 Zeichen inkl. Euro

Bei ISO-8859-1 und Windows-1252 können nicht alle Unicode-Zeichen abgebildet werden. Ein chinesisches Schriftzeichen oder ein Emoji lässt sich nicht in einem 8-Bit-Codepage darstellen. pdftxt.de ersetzt solche Zeichen mit dem Replacement-Char ? und gibt einen Warning zurück, damit der Nutzer das Problem sieht und ggf. auf UTF-8 umstellt.

Heuristik für Scan-Detektion

Damit Nutzer bei gescannten PDFs nicht überrascht ein leeres TXT bekommen, prüft pdftxt.de nach dem PDF.js-Lauf, ob die Seite signifikant Text enthielt. Die Heuristik ist bewusst einfach: wenn weniger als 10 Zeichen pro Seite extrahiert wurden, gilt die Seite als wahrscheinlich gescannt. In diesem Fall blendet die UI einen Banner-Hinweis ein, der den Nutzer fragt, ob er OCR aktivieren möchte. Das vermeidet die schlechte UX, dass der Nutzer ein leeres TXT herunterlädt und sich fragt, was passiert ist.

Privacy-by-Design, kein Server-Upload

Die PDF-Datei verlässt den Browser nicht. Sie können das in den Entwicklertools unter dem Netzwerk-Tab selbst verifizieren: beim Klick auf Konvertieren wird kein ausgehender Request mit dem Datei-Inhalt gestartet. Das macht pdftxt.de geeignet für vertrauliche Mandantenakten in Anwaltskanzleien, Patientenunterlagen in Arztpraxen, Klausurkorrekturen in Hochschulen oder interne Memos in Unternehmen, bei denen ein Cloud-Konverter wie iLovePDF oder Smallpdf nicht in Frage kommt.

Technisch funktioniert das so: nach dem File-Drop wird der File-Inhalt als ArrayBuffer gelesen und direkt an die PDF.js-Worker-Instanz übergeben. Der gesamte Parse- und ggf. OCR-Schritt läuft in-Worker, das Ergebnis als String bleibt im Browser-Speicher. URL.createObjectURL() erzeugt einen lokalen Blob-URL für den Download. Einzige externe Loads bei aktiver OCR: das Sprachmodell vom Tessdata-CDN (statisches Asset, kein Datei-Upload).

10-MB-Grenze

PDFs bis 10 MB werden unterstützt. Die Prüfung erfolgt clientseitig vor dem PDF.js-Load. Sehr große PDFs (mehrere hundert Seiten) können den Browser-Arbeitsspeicher bei OCR-Lauf an die Grenze bringen; in solchen Fällen empfehlen wir, mit der Seitenauswahl gezielt Bereiche zu konvertieren (zum Beispiel 1-10, 25) statt der ganzen Datei.

Was pdftxt.de nicht macht

Keine Server-Verarbeitung: weder PDF.js noch Tesseract.js laufen auf unserem Server, beide leben ausschließlich im Browser-Tab
Kein OCR-Training: die Tesseract-Modelle werden nicht mit deinen Dateien weiter trainiert
Keine Inhaltsanalyse: kein KI-Training, keine Klassifikation, keine PII-Extraktion
Kein dauerhaftes Logging: auch die WASM-Engines selbst loggen nichts
Kein Tabellenstruktur-Erhalt im MVP: Tabellen werden als Lauftext extrahiert, für strukturierte Tabellen-Extraktion sind Camelot oder Tabula die richtigen Werkzeuge
Kein Tracking-Pixel im Tool: AdSense und Google-Analytics laufen nicht, nur optional Umami als anonyme Statistik

Korrektur-Policy

Wenn dir ein Bug auffällt (etwa ein falsches Extraktions-Ergebnis, ein OCR-Aussetzer oder ein inhaltlicher Fehler in einem Ratgeber), schreib an info@akara-solutions.de. Bestätigte Korrekturen dokumentieren wir öffentlich unter Korrekturen.

Verantwortung

Für die Engine und ihre redaktionelle Pflege sind Mateusz Viola (PDF.js-Worker, Tesseract-Singleton, Encoding-Mathematik), Jan-Tristan Rudat (PDF-Geschichte 1993, ISO 32000, DOCX-/Markdown-Vergleich) und Eike-Christian Ramcke (UrhG, DSGVO Art. 6 lit. f) zuständig. Inhaltlich Verantwortlicher gem. § 18 Abs. 2 MStV ist Eike-Christian Ramcke, Geschäftsführer der AKARA Solutions GmbH (vollständige Angaben im Impressum).

Quellen

Mozilla: PDF.js, PDF reader in JavaScript. github.com/mozilla/pdf.js, abgerufen 2026.
Naptha / Project Naptha: Tesseract.js, Pure JavaScript OCR for 100+ Languages. github.com/naptha/tesseract.js.
ISO 32000-1:2008: Document management, Portable document format, Part 1: PDF 1.7.
ISO 32000-2:2020: Document management, Portable document format, Part 2: PDF 2.0.
Adobe Systems: PDF Reference, Sixth Edition, Version 1.7, 2006.
Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), insbesondere Art. 6 Abs. 1 lit. f (berechtigtes Interesse).
Urheberrechtsgesetz (UrhG) §§ 16, 23, 53 und §§ 60a-h in der aktuellen Fassung.

So konvertiert pdftxt.de

Wichtiger Hinweis