Warum Formatierungsverluste bei PDF-zu-Word schlimmer sind
als die meisten Nutzer glauben

PDF speichert nicht, was Sie denken

Microsoft Word speichert ein Dokument als Hierarchie semantischer Elemente: eine Überschrift, gefolgt von einem Absatz, gefolgt von einer nummerierten Liste, gefolgt von einer Tabelle mit drei Spalten. Jedes Element trägt eigene Formatierungsregeln und Beziehungen zu den umliegenden Elementen. Wenn Sie einen Satz zu einem Absatz hinzufügen, berechnet Word das Seitenlayout von Grund auf neu, weil es weiß, was ein Absatz ist.

PDF speichert nichts davon.

Die PDF-Spezifikation — ISO 32000-1:2008, der internationale Standard, der das Format definiert — beschreibt eine Seite als eine Abfolge von Zeichenanweisungen. Ein Textelement in PDF ist nicht „Absatz 3, Satz 2". Es ist: „Zeichen 'A' an Koordinaten (124,5; 356,2) in Helvetica 10pt rendern, gefolgt von Zeichen 'c' an (131,8; 356,2), gefolgt von 'c' an (137,2; 356,2)..." Jedes Zeichen wird unabhängig auf der Seite positioniert. PDF speichert keine Informationen darüber, welche Zeichen zu welchem Wort gehören, welche Wörter zu welcher Zeile, welche Zeilen einen Absatz bilden oder welcher Absatz eine Überschrift ist.

Ein vielzitierter technischer PDF-Leitfaden formuliert es knapp: „PDF erkennt keine Absätze, Formatierungen, Kopfzeilen, Fußzeilen, Einzüge oder getrennte Wörter (Zeilenumbrüche). Text wird in Fragmente zerlegt, die so klein wie einzelne Zeichen, aber nicht länger als eine Zeile sind."

Es gibt eine optionale Erweiterung namens Tagged PDF (definiert in Klausel 14.8 von ISO 32000), die logische Strukturen — Überschriftsebenen, Absatzgrenzen, Tabellensemantik — in eine PDF-Datei einbetten kann. Aber Tagged PDF ist in erster Linie eine Barrierefreiheitsfunktion, und die überwältigende Mehrheit der im Umlauf befindlichen PDFs wurde nicht damit erstellt. Selbst im Adobe-Supportforum erklären Experten, dass die Konvertierungsqualität davon abhängt, „wie gut der Strukturbaum des PDFs ausgebildet ist" — mit der Implikation, dass die meisten PDFs keinen haben.

Das ist das Erste, was die meisten PDF-zu-Word-Konverter-Anbieter Ihnen nicht verraten: Die Dokumentstruktur, die Sie auf dem Bildschirm sehen, existiert in der Datei nicht. Jedes Konvertierungstool muss sie von Grund auf neu rekonstruieren, nur anhand der verstreuten (x,y)-Koordinaten einzelner Zeichen. Und diese Rekonstruktion ist eine dreistufige Kette von fundierten Vermutungen — jeder Schritt potenziert die Fehler des vorherigen.

Die Drei-Fehler-Kette, die jede Konvertierung zerstört

Bei der Konvertierung eines PDFs in ein bearbeitbares Word-Dokument sind drei aufeinanderfolgende Rekonstruktionsschritte erforderlich. Bei jedem Schritt trifft die Software Entscheidungen auf Basis unvollständiger Informationen. Jede Fehlentscheidung wirkt sich auf den nächsten Schritt aus und erzeugt ein Ergebnis, das zunehmend vom Original abweicht.

Fehler 1: Zeichenbasierte OCR — die falschen Zeichen erkennen

Bei gescannten oder bildbasierten PDFs (bei denen Text als Pixel und nicht als auswählbare Zeichen vorliegt) ist der erste Schritt die optische Zeichenerkennung (OCR) — eine Software, die jede winzige Region des Seitenbilds untersucht und versucht, das darin enthaltene Zeichen zu identifizieren. Die OCR arbeitet zeichenweise. Eine Seite mit 3.000 Zeichen erfordert 3.000 unabhängige Erkennungsentscheidungen.

Selbst hochwertige OCR-Engines machen Fehler. Ein Staubkorn auf dem Scannerglas verwandelt einen Punkt in ein Komma. Ein kontrastarmer Textabschnitt führt dazu, dass 'rn' als 'm' gelesen wird. Eine ungewöhnliche Schriftart macht 'I' (großes I), 'l' (kleines L) und '1' (Ziffer Eins) ununterscheidbar. Selbst bei einer Zeichengenauigkeit von 99 % – was als exzellent gilt – entstehen auf einer Seite mit 3.000 Zeichen immer noch 30 falsche Zeichen.

Doch Zeichenfehler sind das sichtbare Problem. Das tiefere Problem tritt selbst dann auf, wenn die OCR jedes Zeichen korrekt erkennt: Sie zeichnet nur die Position jedes Zeichens auf der Seite auf – und sonst nichts. Diese Positionsdaten fließen direkt in den nächsten Rekonstruktionsschritt ein.

Fehler 2: Koordinaten-Rekonstruktion — Erraten, was zusammengehört

Sobald der Konverter eine Liste von Zeichen und deren (x,y)-Koordinaten hat, muss er eine Reihe von Fragen beantworten, für die es in den Daten keine eindeutige Antwort gibt:

• Welche Zeichen bilden ein Wort? Zeichen, die räumlich nah beieinander liegen, gehören wahrscheinlich zum selben Wort – aber was ist mit Blocksatz, bei dem die Wortabstände stark variieren? Was ist mit einer Dezimalzahl, bei der der Punkt näher an der nächsten Ziffer liegt als an der vorherigen?
• Welche Wörter bilden eine Zeile? Wörter mit ungefähr derselben y-Koordinate gehören wahrscheinlich zur selben Zeile – aber was ist mit einem hochgestellten Fußnotenzeichen, das auf derselben y-Position liegt wie die Zeile über der, zu der es gehört?
• Welche Zeilen bilden einen Absatz? Zeilen mit ähnlichem linken Rand und vertikaler Nähe gehören wahrscheinlich zum selben Absatz – aber was ist mit der letzten Zeile eines Absatzes, die kürzer ist als die anderen? Was ist mit einem mehrspaltigen Layout, bei dem der untere Rand von Spalte 1 räumlich näher am oberen Rand von Spalte 2 liegt als an der nächsten Zeile in Spalte 1?

Jede dieser Entscheidungen wird rein aufgrund räumlicher Nähe getroffen. Die Software hat kein Verständnis dafür, was der Text bedeutet. Ein hochgestellter Fußnotenhinweis – sagen wir "¹⁴" – wird in den Absatztext eingefügt, weil er räumlich nah ist. Ein seitliches Zitat mit großer Schrift wird in den Fließtext eingestreut, weil sich seine y-Koordinaten überschneiden. Der Konverter erstellt eine Dokumentstruktur aus einem Punktdiagramm. Es wäre bemerkenswert, wenn er keine Fehler machen würde.

Fehler 3: Layout-Raten — Erfundene Struktur, die nie da war

Nachdem Zeichen zu Wörtern und Wörter zu Zeilen gruppiert wurden, steht der Konverter vor seiner schwersten Aufgabe: zu entscheiden, was das Layout des Dokuments eigentlich ist. Ist dieser große, fette Text eine Überschrift oder nur ein einzeiliger Absatz in großer Schrift? Ist dieser Textblock unter einem Bild eine Bildunterschrift oder der Beginn des nächsten Abschnitts? Ist dieses Zahlenraster eine Tabelle oder nur Text, der zufällig in Spalten ausgerichtet ist?

Die Software rät. Sie sucht nach Mustern: Zeilen, die sich in regelmäßigen Abständen wiederholen, Text, der in Zeilen und Spalten ausgerichtet ist, Schriftgrößen, die vom Fließtext abweichen. Aber das sind Heuristiken, keine Gewissheiten. Eine gut gestaltete Seite mit großzügigen Weißräumen und durchdachter Typografie erzeugt Layout-Signale, die für einen Algorithmus mehrdeutig sind. Der Konverter rät falsch. Wiederholt.

Dies ist der Schritt, bei dem die meisten sichtbaren Formatierungsfehler auftreten. Ein Dokument, das als PDF makellos aussah, erscheint als Word-Datei mit verstreuten Textfeldern auf der Seite, jedes an eine absolute Position gebunden, die beim ersten Bearbeitungsversuch zerbricht. Das ist kein Konvertierungsfehler — es ist der Konverter, der genau das tut, wofür er entwickelt wurde, mit den einzigen Informationen, die er hat. Die Informationen reichen für die Aufgabe einfach nicht aus.

Tabellen: Wo das ganze System zusammenbricht

Wenn die dreistufige Fehlerkette beschreibt, warum Textlayouts brechen, dann stellen Tabellen ihren katastrophalen Fehlermodus dar. Das Problem ist grundlegend: PDF kennt kein Konzept einer Tabelle.

Wenn ein PDF das anzeigt, was wie eine Tabelle aussieht — Datenzeilen mit Spaltenüberschriften und Gitternetzlinien — zeichnet es tatsächlich eine Sammlung unabhängiger visueller Elemente: horizontale und vertikale Liniensegmente für Rahmen und einzelne Textzeichen, die innerhalb der resultierenden Gitterzellen positioniert sind. Die PDF-Datei enthält keine Informationen, die die Zelle in Zeile 3, Spalte „Betrag" mit dem Wert 1.247,00 € verbindet. Sie speichert nur „rendere das Zeichen '€' an Position X, dann '1' an Position X+7, dann...", zusammen mit Zeichenanweisungen für die Rahmen.

Das bedeutet, ein Konverter muss:

1. Erkennen, dass Liniensegmente ein Gitter bilden — nicht immer offensichtlich, wenn Rahmen dünn oder fehlen
2. Bestimmen, wie viele Zeilen und Spalten dieses Gitter enthält — leicht durcheinandergebracht durch verbundene Zellen oder unterschiedliche Spaltenbreiten
3. Jedes Zeichen der richtigen Zelle zuweisen — wo ein einzelnes falsch ausgerichtetes Zeichen das gesamte Gitter durcheinanderbringt
4. Raten, ob Zellen mit ähnlichem Inhalt zusammengeführt werden sollten (wie eine Kopfzeile, die zwei Spalten überspannt)
5. Die Lesereihenfolge der Spalten entscheiden — von links nach rechts? von rechts nach links? Beginnt eine umbrechende Zeile innerhalb einer Zelle oder eine neue Zeile?

Es ist eine Abfolge von Vermutungen, die auf Vermutungen aufbauen. Eine Diskussion auf Hacker News unter Entwicklern, die PDF-Parsing-Tools bauen, fasste die Stimmung treffend zusammen: „PDFs ordnen Zeichen nicht immer sequenziell an, manchmal enthalten sie stattdessen absolut positionierte Einzelzeichen." Ein Entwickler beschrieb den gesamten Prozess als „absurd."

Auf Reddit ist die Nutzererfahrung ein einziger Frust. Ein Poster auf r/MicrosoftWord beschrieb das Ergebnis einer PDF-zu-DOCX-Konvertierung als "seltsame Formatierung", die sich jeder Korrektur widersetzte. Ein anderer auf r/Acrobat berichtete, dass nach dem Export eines PDFs nach Word "Absätze in seltsame Textfelder zerfallen und sich alles verschiebt", sobald man eine Bearbeitung versucht. Ein Nutzer auf r/TechnologyProTips fasste jahrelange Erfahrung zusammen: "Ich wurde das schon millionenfach gefragt. [...] Die Formatierung ist weg, bla bla. Ich habe dieses Dokument und versuche seit Tagen, es in DOC zu konvertieren."

Das sind keine Ausnahmen. Das ist das zu erwartende Ergebnis einer Pipeline, die für eine grundlegend andere Aufgabe entwickelt wurde als die, die wir ihr abverlangen.

Warum der Button "Formatierung beibehalten" ein Etikett ist, keine Lösung

Jeder PDF-zu-Word-Konverter bietet eine Option "Formatierung beibehalten" oder "Seitenlayout erhalten". Adobe Acrobat hat sie. Smallpdf hat sie. ILovePDF hat sie. Die Implikation ist: Wenn Sie dieses Kästchen anhaken, sieht Ihr konvertiertes Dokument aus wie das Original.

Was diese Optionen tatsächlich tun, ist wichtig zu verstehen, denn es zeigt, warum die Ergebnisse so fragil wirken. Wenn Sie in den Exporteinstellungen von Adobe Acrobat "Seitenlayout erhalten" wählen, rekonstruiert der Konverter nicht magisch die logische Struktur des Dokuments. Stattdessen platziert er jedes Textstück in ein absolut positioniertes Textfeld in Word — und bildet damit effektiv das Koordinatensystem des PDFs innerhalb eines Word-Dokuments ab.

Das Ergebnis sieht beim Öffnen korrekt aus. Aber sobald Sie versuchen zu bearbeiten — ein Wort hinzufügen, einen Satz löschen, einen Rand anpassen — bricht das gesamte Layout zusammen, weil jedes Textfeld an einer festen Position auf der Seite verankert ist, nicht am umgebenden Inhalt. Sie haben kein bearbeitbares Dokument erhalten. Sie haben einen Screenshot aus Textfeldern bekommen.

Microsofts eigene Dokumentation ist ungewöhnlich offen dazu. Eine offizielle Antwort auf Microsoft Q&A stellt fest: "Es gibt keine Möglichkeit, PDF in Word zu konvertieren und dabei die geeigneten Formatierungsmethoden in Word zu verwenden. Das liegt daran, dass es keine 1:1-Entsprechung in der Handhabung gibt." Eine weitere Antwort ergänzt: "Aus einer anderen Programmdateistruktur konvertierte Dokumente enthalten immer Formatierungsanomalien und sind oft sehr schwer zu bearbeiten."

Das ist keine Einschränkung, die Adobe oder Microsoft mit einem Software-Update beheben können. Es ist eine kategoriale Beschränkung: Das Quellformat (PDF) und das Zielformat (Word) repräsentieren Dokumente auf fundamental inkompatible Weise. Das eine speichert das Erscheinungsbild. Das andere speichert die Struktur. Erscheinungsbild ohne die ursprünglichen Strukturdaten in Struktur zu konvertieren, ist ein Problem, das nicht gelöst werden kann — nur angenähert, mit unterschiedlichem Grad des Scheiterns.

Unser Vergleich von PDF-zu-Word-Konvertern hat über ein Dutzend Tools mit denselben Dokumenten getestet. Jedes einzelne versagte bei Tabellen mit verbundenen Zellen. Jedes einzelne verstümmelte mehrspaltige Layouts in gewissem Maße. Die Unterschiede lagen darin, wie viel Nachbearbeitung nötig war, nicht ob Nachbearbeitung nötig war. Für eine tiefergehende Erklärung, warum Konvertierung und Datenextraktion grundlegend verschiedene Operationen sind, siehe unseren Vergleich von Dokumentkonvertierung und Datenextraktion.

Wie Vision-KI die gesamte Fehlerkette umgeht

Alles bisher Beschriebene – die zeichenweise OCR, die räumliche Rekonstruktion, das heuristische Layout-Raten – ist die Pipeline, die jeder traditionelle PDF-Konverter verwendet. Es ist die einzige verfügbare Pipeline, wenn Ihr Ausgangspunkt „eine Liste einzelner Zeichen und ihrer Koordinaten“ ist.

Es gibt jedoch einen grundlegend anderen Ansatz, der die gesamte Fehlerkette umgeht, indem er ändert, was die Software überhaupt betrachtet.

Vision-KI – genauer gesagt, visuelle Sprachmodelle (VLMs), die auf Millionen von Dokumentbildern trainiert wurden – liest nicht Zeichen für Zeichen. Es sieht die gesamte Seite als visuelle Einheit, so wie ein Mensch es tut. Wo OCR dies sieht:

Vision-KI sieht:

Der Unterschied ist kategorial. OCR erzeugt Zeichenpositionen. Vision-KI erzeugt Dokumentverständnis.

Weil Vision-KI versteht, was es sieht, kann es ein natives Word-Dokument erzeugen – keine Sammlung positionierter Textfelder, sondern echte Word-Absätze, echte Word-Überschriften, echte Word-Tabellen mit der korrekten Anzahl von Zeilen und Spalten. Die Ausgabe verhält sich wie ein von Anfang an in Word erstelltes Dokument: Sie können Text zu einem Absatz hinzufügen, und der darunterliegende Text fließt natürlich; Sie können eine Tabellenspalte in der Größe ändern, und die benachbarten Spalten passen sich an; Sie können einen neuen Überschriftenstil anwenden, und er verbreitet sich im gesamten Dokument.

Dies macht der Nach Word-Modus von ImageToTable.ai. Anders als herkömmliche PDF-zu-Word-Konverter versucht er gar nicht erst die Pipeline OCR → Koordinatenrekonstruktion → Layout-Raten. Stattdessen analysiert ein visuelles Sprachmodell das gesamte Seitenbild – egal ob digitales PDF, gescanntes Dokument, Screenshot oder Handyfoto einer gedruckten Seite – und gibt ein strukturiertes Word-Dokument mit Absätzen, Überschriften und Tabellen aus. Keine Vorlagen, kein Training, keine dokumentenspezifische Konfiguration. Wenn Sie das vollständige technische Bild davon möchten, wie KI-Visionsmodelle Dokumente anders als OCR verarbeiten, führt Sie unser verständlicher Leitfaden zur KI-Dokumentenlesung im Detail durch die Mechanik.

Dieser Ansatz bedeutet auch, dass der To-Word-Modus gescannte Dokumente und digitale PDFs identisch behandelt. Beide sind für ein Vision-Modell lediglich Bilder. Es gibt keinen separaten Schritt „Erst OCR, dann konvertieren“, da Zeichenerkennung und Layout-Verständnis gleichzeitig ablaufen – gestützt durch das Verständnis des Modells für Dokumentenstrukturen. Mehr zur Entwicklung der OCR-Technologie und den Veränderungen der letzten drei Jahre finden Sie in unserer Analyse: Was nach OCR geschah.

Das Ergebnis ist das, was traditionelle Konverter-Anbieter schon immer mit ihrem „Formatierung erhalten“-Button versprochen, aber nie geliefert haben: ein Word-Dokument, bei dem Sie den Inhalt bearbeiten können, ohne das Layout von Grund auf neu aufbauen zu müssen. Für das vollständige technische Bild der layout-erhaltenden Dokumentenkonvertierung – einschließlich der zugrundeliegenden Mechanismen, einem Vergleich der Ansätze und einer Auswahlhilfe – lesen Sie unseren vollständigen Leitfaden zur layout-erhaltenden Dokument-zu-Word-Konvertierung.

Häufig gestellte Fragen

Funktioniert das mit gescannten PDFs oder nur mit digitalen?

Vision AI behandelt beide identisch. Ein gescanntes PDF ist ein Abbild einer Seite; ein digitales PDF, das auf dem Bildschirm dargestellt wird, ist ebenfalls ein Abbild einer Seite. Das Vision-Modell verarbeitet direkt das visuelle Erscheinungsbild, daher gibt es keinen Unterschied in der Ausgabequalität zwischen einem gescannten Dokument und einem digital erstellten PDF. Herkömmliche Konverter verschlechtern sich bei Scans erheblich, da sie zuerst eine OCR durchführen müssen, getrennt von der Layout-Rekonstruktion – was die gesamte oben beschriebene Fehlerkette wieder einführt.

Was ist mit handschriftlichen Dokumenten oder Anmerkungen?

Da Vision AI den Kontext versteht, anstatt Zeichenformen mit einer Schriftbibliothek abzugleichen, verarbeitet es Handschrift robuster als OCR. OCR behandelt eine handschriftliche Notiz als eine Reihe mehrdeutiger Formen, die einzeln entschlüsselt werden müssen. Vision AI liest den umgebenden Text, versteht den Zweck des Dokuments und nutzt diesen Kontext, um handschriftliche Markierungen zu interpretieren – genauso wie ein menschlicher Leser. Die Leistung variiert mit der Leserlichkeit der Handschrift, aber der Ansatz unterscheidet sich grundlegend von OCR.

Ist die Word-Ausgabe wirklich bearbeitbar oder bricht sie, wenn ich Änderungen vornehme?

Die Ausgabe ist natives Word – echte Absätze, Überschriften und Tabellen, keine positionierten Textfelder. Sie können Text zu einem Absatz hinzufügen, und der darunterliegende Inhalt fließt natürlich um. Sie können Spaltenbreiten in einer Tabelle anpassen. Sie können Word-Formate anwenden. Das Dokument verhält sich, als wäre es in Word erstellt worden. Dies ist der strukturelle Unterschied zwischen der Ausgabe von Vision AI und der herkömmlicher Konverter: Letztere bewahren das Erscheinungsbild (auf Kosten der Bearbeitbarkeit), während Erstere die Struktur bewahren (wodurch das Erscheinungsbild natürlich folgt).

Wie gut verarbeitet Vision AI komplexe Layouts wie mehrspaltige Berichte oder Formulare?

Vision AI verarbeitet die Seite als visuelle Szene, nicht als Koordinatengitter. Mehrspaltige Layouts, Formulare mit beschrifteten Feldern, Dokumente mit eingebetteten Diagrammen und Bildern – das Modell erkennt diese als semantische Muster, nicht als räumliche Artefakte zur Rekonstruktion. Die Qualität der Ausgabe hängt von der Klarheit und Komplexität des Dokuments ab, aber der Ansatz vermeidet die systematischen Fehlermodi (Spaltenverschränkung, Textfeld-Fragmentierung), die Koordinaten-Rekonstruktionsmethoden innewohnen. Unser Leitfaden zur Layout-Erhaltung behandelt Randfälle und Einschränkungen im Detail.