Methodik & Qualitätssicherung

Wie die Konvertierung funktioniert

Ein PDF kann Text auf zwei sehr verschiedene Arten speichern: als auslesbare Zeichenebene (bei einem aus einem Programm erzeugten PDF) oder nur als Seitenbild (bei einem Scan). Der Konverter erkennt den Fall automatisch und verarbeitet das Dokument in mehreren Stufen, die alle vollständig im Browser laufen:

• Stufe 1, Analyse mit pdfjs: Die Bibliothek öffnet das PDF und prüft pro Seite, ob eine auslesbare Textebene vorhanden ist. Liegt Text vor, liest pdfjs die Zeichen samt ihrer x- und y-Position auf der Seite aus. Aus diesen Positionsdaten wird die Lesereihenfolge rekonstruiert und tabellarisch angeordneter Text grob in Spalten gegliedert.
• Stufe 2, OCR mit tesseract.js (nur bei Bedarf): Hat eine Seite keine Textebene, etwa bei einem Scan, rendert pdfjs sie zunächst zum Bild. tesseract.js führt darauf die Texterkennung in deutscher Sprache durch und liefert den erkannten Text. Diese Stufe wird nur ausgelöst, wenn keine native Textebene existiert.
• Stufe 3, Erzeugung mit der docx-Bibliothek: Der extrahierte oder erkannte Text wird in eine bearbeitbare .docx-Datei geschrieben, gegliedert in Absätze und, wo erkennbar, Überschriften und einfache Tabellen.
• Eingabeformat: .pdf, sowohl mit Textebene als auch als reiner Scan.
• Ausgabeformat: eine bearbeitbare .docx-Datei, die sich in Word, LibreOffice oder Google Docs weiterverarbeiten lässt.

Die gesamte Verarbeitung passiert im Frontend. Die hochgeladene Datei wird nicht an einen Server gesendet, sodass auch sensible Dokumente den Rechner des Nutzers nicht verlassen.

Was an Formatierung erhalten bleibt

Der Konverter ist auf den Textinhalt ausgelegt, nicht auf einen pixelgenauen Nachbau des Layouts. Die folgende Einordnung zeigt, was zuverlässig übernommen wird und wo die client-seitige Verarbeitung Grenzen hat:

• Zuverlässig übernommen: der Fließtext, Absätze und die grundsätzliche Reihenfolge bei einspaltigen Dokumenten. Bei PDF mit Textebene ist der Text zeichengenau, weil er direkt ausgelesen und nicht geschätzt wird.
• Eingeschränkt übernommen: Tabellen werden aus den Textpositionen rekonstruiert. Ein PDF speichert keine logische Tabellenstruktur, sondern nur Text an Koordinaten. Bei einfachen Aufstellungen klappt das gut, bei verschachtelten oder zusammengefassten Zellen kann das Spaltenraster verrutschen und braucht Nacharbeit in Word.
• Mehrspaltiger Satz: Bei zwei- oder dreispaltigen Dokumenten (etwa wissenschaftlichen Papers) wird die Lesereihenfolge aus den Koordinaten geschätzt. An den Spaltengrenzen kann es zu Sprüngen kommen, die vor dem Weiterverarbeiten zu prüfen sind.
• OCR-Genauigkeit: Bei gescannten PDF erkennt tesseract.js die Buchstaben aus dem Bild. Die Erkennung ist gut, aber nicht fehlerfrei. Verwechslungen (1 und l, 0 und O, rn und m), schräge oder unscharfe Scans, Stempel und Handschrift führen zu Fehlern. Zahlen, Beträge, Namen und Daten sind deshalb Zeichen für Zeichen zu prüfen.
• Nicht der Anspruch: ein pixelgenauer Nachbau von Schriften, Logos, Grafiken und Spaltenlayout. Der Konverter holt den bearbeitbaren Text zurück und liefert eine Arbeitsfassung, keine layouttreue Kopie und keine geprüfte Endfassung.

Wo die Daten verarbeitet werden

Alle Dateien werden ausschließlich im Browser des Nutzers verarbeitet. Es findet kein Roundtrip zu einem Server statt:

• Browser-only-Konvertierung: pdfjs, tesseract.js und die docx-Bibliothek laufen als JavaScript im Frontend. Die hochgeladene PDF-Datei und die erzeugte Word-Datei verlassen den Computer des Nutzers nicht.
• Kein Upload, kein Server-Speicher: Die Datei wird nicht hochgeladen, nicht zwischengespeichert und nicht protokolliert. Sie liegt nur flüchtig im Arbeitsspeicher des Browsers und ist nach dem Schließen des Tabs weg.
• Kein Tracking auf Datei-Inhalte: Das eingesetzte Analytics-Tool Umami zählt nur anonymisierte Seitenaufrufe und keine Dateinamen, Inhalte oder erkannten Texte.
• Keine Login-Pflicht, kein Konto, keine API: Das Tool ist vollständig statisch (Astro-Build, Auslieferung über Netlify-CDN). Es ist dadurch DSGVO-konform, weil keine personenbezogenen Dokumentinhalte verarbeitet oder gespeichert werden. Das ist gerade bei Verträgen, Rechnungen und Behörden-Formularen relevant.

Wer redaktionell verantwortlich ist

Mateusz Viola ist Betreiber von pdf-word.de und tagesverantwortlich für Pflege, Konverter-Logik und Inhalte. Vollständiges Profil unter /autoren/mateusz-viola/.

Eike-Christian Ramcke, Geschäftsführer der AKARA Solutions GmbH, ist inhaltlich Verantwortlicher gemäß § 18 Abs. 2 MStV und verantwortet die rechtlich relevanten Inhalte (DSGVO-konforme Verarbeitung, OCR-Genauigkeit, Abgrenzung zwischen maschinell extrahiertem Text und einer geprüften, verbindlichen Fassung). Vollständiges Profil unter /autoren/eike-christian-ramcke/. Anschrift und Kontaktdaten zusätzlich im Impressum.

Die Aufbereitung der Beispiel-Inhalte und Praxis-Ratgeber verantwortet Jan-Tristan Rudat als Redakteur. Profil unter /autoren/jan-tristan-rudat/.

Wie Korrekturen entstehen

Inhaltliche Fehler werden offen dokumentiert. Der Ablauf:

1. Hinweis per Mail an mateusz.viola@akara-solutions.de mit Verweis auf die Seite und die fragliche Stelle.
2. Interner Review innerhalb von sieben Werktagen. Bei technischen Aussagen zur Konvertierung wird gegen den PDF-Standard (ISO 32000) und die Dokumentation von pdfjs, tesseract.js und der docx-Bibliothek gegengeprüft.
3. Bei bestätigtem Fehler wird der Artikel angepasst und ein Eintrag in der öffentlichen Korrektur-Liste erstellt mit Datum, Stelle und Korrektur.
4. Der Hinweisgeber erhält eine Bestätigung der Änderung.