Methodik & Qualitätssicherung

Wie die Konvertierung funktioniert

Eine .docx-Datei ist im Kern ein ZIP-Archiv mit XML-Dateien nach dem Office-Open-XML-Standard (ECMA-376). Der Konverter verarbeitet sie in zwei Stufen, beide laufen vollständig im Browser:

• Stufe 1, Parsing mit mammoth: Die Bibliothek liest die document.xml samt zugehöriger Styles und Relationships aus dem Archiv und übersetzt die Dokumentstruktur in semantisches HTML. Aus Word-Absatzstilen werden Überschriften, aus Listen ul/ol, aus Tabellen table-Elemente.
• Stufe 2, Rendering mit jsPDF: Das erzeugte HTML wird auf festen A4-Seiten ausgerendert. jsPDF setzt Text, Umbrüche und Tabellen und schreibt die verwendeten Schriften in die PDF-Datei, damit sie auf jedem Gerät gleich erscheinen.
• Unterstützte Eingabeformate: .docx und .doc. Das ältere .doc-Binärformat wird vor dem Parsing in die XML-Struktur überführt; aufwendig formatierte Altdokumente können dabei vereinfacht werden.
• Ausgabeformat: ein durchsuchbares PDF mit eingebetteten Schriften, Seitengröße A4.

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 textorientierte Dokumente ausgelegt. Die folgende Einordnung zeigt, was zuverlässig übernommen wird und wo die client-seitige Verarbeitung Grenzen hat:

• Zuverlässig übernommen: Fließtext, Überschriftenebenen, Fett und Kursiv, Aufzählungen und nummerierte Listen, Absätze sowie der grundsätzliche Aufbau von Tabellen.
• Schriften: Standard-PDF-Schriften erscheinen exakt. Verbreitete Systemschriften wie Arial oder Calibri werden auf eine passende Standardschrift abgebildet. Spezielle Designschriften werden auf eine ähnliche Schrift mit vergleichbaren Proportionen abgebildet, nicht pixelgenau.
• Vereinfacht: komplexe mehrspaltige Layouts, frei positionierte Textfelder, exakte Spaltenbreiten in Tabellen und Kopf-/Fußzeilen mit dynamischen Feldern. Hier kann das Ergebnis vom Word-Original abweichen.
• Nicht der Anspruch: ein pixelgenauer Nachbau aufwendig gestalteter Layouts. Wer das braucht, exportiert in Word direkt über "Speichern unter > PDF", weil Word die Original-Layout-Engine nutzt. Der Konverter zielt auf eine schnelle, datenschutzkonforme Umwandlung im Browser ohne installierte Software.

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: mammoth und jsPDF laufen als JavaScript im Frontend. Die hochgeladene Word-Datei und das erzeugte PDF 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 Ergebnisse.
• 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.

Wer redaktionell verantwortlich ist

Mateusz Viola ist Betreiber von word-pdf.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, PDF-Unveränderbarkeit, Abgrenzung zur elektronischen Signatur). 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 Office-Open-XML-Standard (ECMA-376) und die Dokumentation von mammoth und jsPDF 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.