Ratgeber · Word zu PDF 2026
DOCX verstehen: OOXML, ZIP-Container und XML
Der technische Aufbau des DOCX-Formats: OOXML als ISO-Standard, der ZIP-Container, document.xml und warum das Format gut maschinenlesbar ist.
DOCX ist kein einzelnes Dokument, sondern ein Archiv
Wer eine Datei mit der Endung .docx doppelklickt, sieht in Word ein Schriftstück. Technisch handelt es sich aber nicht um eine einzelne Datei, sondern um ein ZIP-Archiv, das mehrere XML-Dateien, Bilder und Konfigurationsdaten bündelt. Benennt man eine .docx in .zip um, lässt sie sich mit jedem Packprogramm öffnen und der Aufbau wird sichtbar. Das ist kein Trick, sondern Teil der offiziellen Spezifikation.
Das Format heißt Office Open XML, kurz OOXML, und ist seit 2008 als internationaler Standard normiert (ISO/IEC 29500). Microsoft führte es mit Word 2007 ein und löste damit das alte binäre .doc ab. Das "x" am Ende von docx, xlsx und pptx steht für genau diesen XML-Kern.
Der Blick ins Innere des Containers
Entpackt man eine typische .docx, findet man eine klar strukturierte Ordnerhierarchie:
| Pfad im Archiv | Inhalt |
|---|---|
| /word/document.xml | Der eigentliche Text mit allen Absätzen und Formatierungs-Tags |
| /word/styles.xml | Definition der Formatvorlagen (Überschrift 1, Standard, Zitat) |
| /word/media/ | Eingebettete Bilder als separate PNG- oder JPEG-Dateien |
| /word/fontTable.xml | Liste der verwendeten Schriftarten |
| /docProps/core.xml | Metadaten: Autor, Titel, Erstellungsdatum |
| /[Content_Types].xml | Verzeichnis aller enthaltenen Dateitypen |
| /_rels/ | Beziehungen zwischen den Teilen (welches Bild gehört wohin) |
Diese Trennung hat einen praktischen Vorteil: Text und Bilder liegen getrennt vor. Wer nur den Text einer beschädigten Datei retten will, kann document.xml einzeln aus dem Archiv ziehen und auslesen. Bei einer alten .doc war das nahezu unmöglich, weil dort alles in einem undurchsichtigen Binärblock steckte.
So sieht der XML-Text aus
Ein einzelner Absatz mit dem Wort "Hallo" sieht in document.xml ungefähr so aus:
<w:p><w:r><w:t>Hallo</w:t></w:r></w:p>
Dabei steht w:p für einen Absatz (paragraph), w:r für einen zusammenhängenden Textlauf (run) mit einheitlicher Formatierung und w:t für den reinen Text (text). Wird ein Wort fett gesetzt, bekommt der zugehörige run eine Eigenschaft <w:b/> mitgegeben. Diese Verschachtelung macht das Format zwar geschwätzig, aber maschinell sehr gut auswertbar.
Warum das für die PDF-Umwandlung wichtig ist
Weil DOCX ein offener XML-Standard ist, kann jede Software die Struktur lesen, ohne Microsoft-Code zu benötigen. Genau das nutzt die Umwandlung in PDF aus. Eine JavaScript-Bibliothek wie mammoth.js öffnet das ZIP-Archiv im Browser, liest document.xml aus und übersetzt die Absatz- und Formatierungs-Tags in sauberes HTML. Aus diesem HTML erzeugt anschließend eine Bibliothek wie jsPDF die fertige PDF-Seite.
Der gesamte Vorgang läuft dabei lokal im Browser ab. Es ist kein installiertes Word nötig, weil die Struktur offengelegt und standardisiert ist. Genau dieser offene Charakter unterscheidet DOCX grundlegend vom alten binären Vorgänger, mehr dazu im Ratgeber DOC vs. DOCX.
Grenzen der Lesbarkeit
Nicht jedes Element überträgt sich verlustfrei. mammoth konzentriert sich bewusst auf den semantischen Inhalt: Überschriften, Absätze, Listen, Fettungen, Links und Bilder. Komplexe Layout-Elemente wie genau positionierte Textfelder, Spaltensatz oder eingebettete Diagramme bildet das HTML-Zwischenformat nur eingeschränkt ab. Wer ein streng gestaltetes Layout exakt erhalten will, sollte das im Ratgeber Formatierung erhalten nachlesen.
Metadaten: Was eine DOCX über Sie verrät
In docProps/core.xml und docProps/app.xml stehen Metadaten, die viele Nutzer übersehen. Dazu gehören der zuletzt speichernde Benutzername, die Gesamtbearbeitungszeit, die Anzahl der Überarbeitungen und teils der Firmenname aus der Office-Lizenz. Wer ein Dokument anonym weitergeben will, sollte diese Felder vor dem Versand bereinigen. Word bietet dafür unter "Datei, Informationen, Auf Probleme überprüfen, Dokument prüfen" eine Funktion zum Entfernen.
Bei der Umwandlung in PDF werden diese DOCX-internen Metadaten nicht automatisch übernommen, das PDF erhält seine eigenen, meist leeren Metadatenfelder. Für vertrauliche Unterlagen ist das ein willkommener Nebeneffekt, weil so unbeabsichtigt mitgespeicherte Informationen wegfallen.
DOCX gegen ODT und RTF
| Format | Typ | Standard |
|---|---|---|
| DOCX | ZIP mit XML (OOXML) | ISO/IEC 29500 |
| ODT | ZIP mit XML (OpenDocument) | ISO/IEC 26300 |
| RTF | Reiner Text mit Steuerzeichen | Microsoft-Spezifikation |
| DOC | Binärformat (OLE) | proprietär, dokumentiert |
ODT ist das Pendant aus der LibreOffice-Welt und technisch sehr ähnlich aufgebaut, ebenfalls ein ZIP-Container mit XML. RTF ist deutlich älter und speichert alles als lesbaren Text mit geschweiften Klammern und Backslash-Befehlen, was es robust, aber speicherhungrig macht.
Strict und Transitional: zwei Spielarten von OOXML
Die OOXML-Norm kennt zwei Varianten. Transitional wurde geschaffen, um alte Binär-Dokumente verlustfrei nach XML zu überführen, und enthält deshalb viele Altlasten und herstellerspezifische Erweiterungen. Strict ist die aufgeräumte, vollständig standardkonforme Variante ohne diese Sonderfälle. In der Praxis speichert Word standardmäßig im Transitional-Modus, weil das die größte Kompatibilität mit bestehenden Dokumenten sichert. Für Werkzeuge, die DOCX auslesen, bedeutet das: Sie müssen auch mit den Transitional-Eigenheiten umgehen können, sonst scheitern sie an Dateien aus älteren Word-Versionen.
Die Rolle der Relationships
Ein oft übersehener Teil des Containers ist der Ordner _rels. Darin liegen Beziehungsdateien, die festlegen, welcher Bestandteil auf welchen anderen verweist. Wenn document.xml ein Bild einbindet, steht dort kein direkter Dateipfad, sondern eine Relationship-ID wie rId5. Erst die zugehörige .rels-Datei löst diese ID zur tatsächlichen Bilddatei in /word/media auf. Dieses indirekte Verfahren erlaubt es, Bestandteile zu verschieben oder auszutauschen, ohne den Haupttext anfassen zu müssen, und ist ein Grund, warum DOCX so robust gegenüber Teilbeschädigungen ist.
Wie ein Konverter den Container verarbeitet
Der typische Ablauf bei einer browser-basierten Umwandlung sieht so aus:
- Die .docx wird über die File-API des Browsers eingelesen, ohne sie auf einen Server zu schicken.
- Eine ZIP-Bibliothek entpackt das Archiv im Arbeitsspeicher.
- mammoth.js liest document.xml und styles.xml, ordnet den Absätzen ihre Formatvorlagen zu und erzeugt semantisches HTML.
- Eingebettete Bilder aus /word/media werden als Base64-Daten in das HTML übernommen.
- jsPDF rendert dieses HTML in feste PDF-Seiten und stellt die Datei zum Download bereit.
Jeder dieser Schritte arbeitet ausschließlich mit der offengelegten Struktur. Es gibt keinen versteckten Aufruf an Microsoft-Code, weshalb der gesamte Vorgang auch offline und ohne Office funktioniert.
Zum Mitnehmen
DOCX ist ein gepacktes Archiv aus XML-Dateien, kein monolithisches Dokument. Diese Offenheit ist der Grund, warum sich Word-Dateien heute zuverlässig und sogar komplett im Browser in PDF umwandeln lassen, ohne dass Microsoft-Software im Spiel sein muss. Wer den Aufbau einmal verstanden hat, begreift auch, warum manche Elemente sich besser übertragen als andere und warum eine teilbeschädigte Datei oft noch zu retten ist.
Quellen: ISO/IEC 29500 "Office Open XML File Formats"; ECMA-376 Spezifikation; mammoth.js Dokumentation auf GitHub.
Häufige Fragen