MarkFlow
Zurück zum Blog
Blog Article2026-04-22

Obsidian nach Word: Der komplette Export-Leitfaden für 2026

DA
Daipeng (sosojustdo)
11 min read

Obsidian-Vault, der mit erhaltener Formatierung in ein Microsoft-Word-Dokument konvertiert wurde

Wer in Obsidian lebt, kennt das Problem bereits. Man hat drei Monate lang eine Forschungsnotiz aufgebaut, voll mit Obsidian-spezifischer Syntax — Dinge wie:

[[Project Plan]]        → link to another note
![[diagram.png]]        → embedded image
> [!note] Key insight   → callout block

Dann fragt ein Kollege nach der Word-Version — und jedes einzelne dieser nicht-standardisierten Elemente zerbricht.

Ich bin das erste Mal darüber gestolpert, als ich eine 40-seitige technische Untersuchung an einen Stakeholder übergeben musste, der Obsidian nicht anfassen wollte. Was im Vault poliert aussah, kam in Word als Durcheinander aus literalen Klammern und verwaisten Bild-Platzhaltern heraus. Nachdem ich mich durch diese Konvertierung und seither mehrere weitere gearbeitet habe, habe ich mich auf einen Workflow festgelegt, der hält. Dieser Leitfaden dokumentiert ihn — den Vorverarbeitungsschritt, den die meisten überspringen, die drei Obsidian-spezifischen Eigenheiten, die wirklich zählen, und was zu tun ist, wenn Bilder oder Callouts sich querstellen.

Warum Obsidians Markdown nicht portabel ist (und was zerbricht)

Obsidian speichert Notizen als einfache .md-Dateien, weshalb viele annehmen, der Export nach Word sei trivial. Ist er nicht — denn Obsidian erweitert Standard-Markdown um Funktionen, die kein generischer Konverter versteht.

Gegenüberstellung der Obsidian-spezifischen Markdown-Syntax und der CommonMark-Standardausgabe

Hier sind die vier Erweiterungen, die fast jeden misslungenen Export verursachen:

Obsidian-SyntaxBedeutungWas in Word passiert
[[Project Plan]]Wikilink zu einer anderen NotizErscheint als literaler Text [[Project Plan]]
![[diagram.png]]Eingebetteter AnhangErscheint als literaler Text, Bild geht verloren
> [!warning] TitleCallout-BlockWird zu einem einfachen Blockzitat, Kopfzeile geht verloren
dataview-CodeblöckeDynamisches Abfrage-ErgebnisExportiert als Roh-Query, nicht als gerenderte Tabelle

Standard-Markdown-Konverter — Pandoc, die meisten Online-Tools — behandeln [[...]] als literalen Text und ![[...]] als unbekanntes Token. Die gerenderte Obsidian-Ansicht, die Sie in der App sehen, ist eine Vorschau, nicht die Quelle. Diese Unterscheidung ist die Wurzel der meisten „Warum ist mein Export kaputt?"-Frustrationen.

Es gibt noch ein subtileres Problem: Anhang-Pfade. Obsidian löst ![[image.png]] auf, indem es Ihren Vault nach einer passenden Datei durchsucht — unabhängig vom Ordner. Standard-Markdown braucht einen expliziten relativen Pfad. Wenn Ihr Vault Anhänge in 99 Attachments/ ablegt und Ihre Notiz in 10 Projects/ liegt, muss der Bildlink umgeschrieben werden, bevor irgendein Konverter ihn finden kann.

Vor dem Export: Der Vorverarbeitungsschritt, der Sie rettet

Der größte einzelne Zugewinn an Zuverlässigkeit in meinem Workflow kam durch einen 5-minütigen Vorverarbeitungsdurchlauf vor dem Ausführen eines Konverters. Überspringt man das, verbringt man hinterher 30 Minuten damit, die Word-Datei aufzuräumen.

Obsidian-Vault-Struktur mit getrennten Ordnern für Notizen und Anhänge

Schritt 1: Anhang-Einstellungen prüfen

Öffnen Sie Settings → Files and links. Merken Sie sich zwei Werte:

  • Default location for new attachments — wo neue Bilder/PDFs landen
  • New link format — wie Obsidian Pfade schreibt (Shortest path when possible, Relative path to file oder Absolute path in vault)

Steht das auf Shortest path when possible (Obsidians Standard), zerbricht Ihr Export bei jeder Notiz, deren Anhänge nicht im selben Ordner liegen. Stellen Sie vor dem Export auf Relative path to file um. Diese Einstellung gilt nur für die Zukunft — bestehende Links behalten ihr altes Format, bis sie umgeschrieben werden. Schritt 2 unten kümmert sich um genau diese Umschreibung.

Schritt 2: Wikilinks in Standard-Markdown-Links konvertieren

Obsidian hat dafür einen eingebauten Schalter: Settings → Files and links → Use [[Wikilinks]] → OFF. Ist er aus, werden neue Links als [Note Name](Note-Name.md) geschrieben. Aber das betrifft nur neue Links.

Um bestehende [[wikilinks]] in einer Notiz zu konvertieren, haben Sie zwei Möglichkeiten:

  1. Manuell bei kleinen Exporten — Cmd/Strg+F in der Notiz, jedes [[ suchen, umschreiben. Für eine 5-Seiten-Notiz völlig in Ordnung.
  2. Community-Plugin für größere Vaults — öffnen Sie Settings → Community plugins und suchen Sie nach Begriffen wie „link converter" oder „markdown links". Mehrere Plugins im Ökosystem konvertieren Wikilinks (und eingebettete ![[...]]-Anhänge) gesammelt in Standard-Markdown-Syntax — entweder für die aktuelle Datei oder einen ganzen Ordner. Wählen Sie eines mit aktuellen Updates und einer Nutzerzahl, die Ihnen Vertrauen gibt.

Nach dem Umschreiben sehen Ihre eingebetteten Anhänge so aus: ![image.png](path/to/image.png). Prüfen Sie die Ausgabe — enthält Ihr Anhang-Ordner Leerzeichen, kodieren Sie diese als URL (My%20Vault/attachment.png), sonst verwirft der Konverter das Bild stillschweigend.

Schritt 3: Entscheiden, was mit Callouts passieren soll

Obsidian-Callouts (> [!note], > [!warning] usw.) sind im Vault wertvoll, haben in Word aber kein Gegenstück. Sie haben drei Optionen, nach Aufwand sortiert:

  • Die Abstufung akzeptieren — sie werden zu einfachen Blockzitaten. Der Callout-Typ (note/warning/tip) geht verloren, der Inhalt überlebt. Für die meisten Übergaben akzeptabel.
  • Die wichtigen umschreiben — ersetzen Sie > [!warning] Critical vor dem Export durch > **⚠️ Critical:**. Lesbar an beiden Stellen.
  • In Word nachbearbeiten — Blockzitate mit Words Schnellformatvorlagen in gestylte Kästen umwandeln. Nur bei wirklich polierten Lieferungen lohnenswert.

Ich nutze Option 2 für alles unter 20 Seiten und Option 1 für alles andere.

Schritt 4: Dataview-Blöcke als statische Inhalte exportieren

Enthält Ihre Notiz Dataview-Abfragen, werden sie als Query-Code exportiert, nicht als Ergebnistabelle. Führen Sie die Abfrage vor dem Export in Obsidian aus, kopieren Sie die gerenderte Ausgabe und fügen Sie sie als statische Markdown-Tabelle anstelle des Code-Blocks ein. Ja, das ist manuell. Nein, einen sauberen Weg daran vorbei gibt es nicht — Dataview rendert clientseitig, die Quelldatei enthält die Daten also tatsächlich nicht.

Der Vier-Schritt-Export-Workflow

Workflow-Diagramm in vier Schritten: Obsidian-Vault-Vorverarbeitung, Markdown-Export, Konverter, Word-Dokument-Feinschliff

Ist die Vorverarbeitung erledigt, ist die eigentliche Konvertierung unkompliziert.

1. Die Notiz kopieren (nicht in-place exportieren)

Duplizieren Sie Ihre Zielnotiz samt ihren Anhängen in einen temporären Ordner außerhalb des Vaults. Sie wollen nicht, dass Vorverarbeitungs-Änderungen (Link-Umschreibungen, Callout-Ersetzungen) Ihren Haupt-Vault verschmutzen. Ich halte dafür einen Ordner namens _export-staging/ auf dem Desktop.

2. Anhang-Pfade flach halten

Verschieben Sie alle referenzierten Bilder in denselben Ordner wie die .md-Datei und aktualisieren Sie die Links auf einfache Dateinamen: ![diagram](diagram.png) statt ![diagram](../../99 Attachments/diagram.png). Die meisten Konverter haben Mühe mit Pfaden, die in übergeordnete Ordner springen.

3. Den Konverter laufen lassen

Laden Sie die vorverarbeitete .md-Datei in MarkFlows Markdown-zu-Word-Konverter hoch. Er beherrscht GitHub Flavored Markdown (GFM) — inklusive Tabellen, Aufgabenlisten und Fußnoten — und deckt damit jedes Standard-Feature ab, das Obsidian nach der Vorverarbeitung erzeugt. Bilder werden inline eingebettet, Codeblöcke behalten ihre Syntaxhervorhebung, und Überschriften werden auf Words Heading-Formate abgebildet, sodass Ihr Navigationsbereich im ausgegebenen DOCX funktioniert.

Wenn die Notiz LaTeX-Formeln enthält ($E=mc^2$ oder $$...$$), vergewissern Sie sich, dass der gewählte Konverter sie als Word-Gleichungen bewahrt und nicht zu reinem Text abflacht. Bei Notizen, die von Formeln nur so strotzen — Forschungsprotokolle, akademische Entwürfe — ist das die entscheidende Funktion. Wenn Word nicht das Endziel ist und Sie nur eine teilbare Datei brauchen, umgeht Markdown nach PDF konvertieren Words Eigenheiten beim Formel-Rendering komplett.

4. In Word feinschleifen

Öffnen Sie die DOCX und wenden Sie eine Word-Vorlage an, falls Sie eine haben. Die Heading-Stile aus dem Markdown werden sauber auf Words eingebaute Überschrift 1/2/3 abgebildet — das komplette Restyling des Dokuments ist damit ein Ein-Klick-Vorgang über Design → Document Formatting. Prüfen Sie drei Dinge, bevor Sie die Datei rausschicken:

  • Inhaltsverzeichnis — fügen Sie eines über References → Table of Contents ein, um zu prüfen, ob alle Überschriften korrekt erkannt wurden
  • Bildgrößen — Obsidian zeigt Bilder in ihrer natürlichen Größe, Word bläht sie unter Umständen auf. Bei Bedarf alles markieren und neu skalieren
  • Hyperlinks — externe Links sollten live sein; interne [[wikilinks]] sollten entweder aufgelöst oder entfernt sein

Obsidian-spezifische Sonderfälle

Einige Szenarien tauchen oft genug auf, um sie einzeln zu erwähnen.

Tagesnotizen und Templates

Wenn Sie eine Tagesnotiz exportieren, die {{date}} oder Templater-Variablen verwendet, passiert der Export nachdem Obsidian sie ersetzt hat — die exportierte .md enthält also das echte Datum, nicht den Platzhalter. Keine Sonderbehandlung nötig. Die Ausnahme ist, wenn Sie direkt aus dem Dateisystem exportiert haben, ohne die Notiz vorher in Obsidian zu öffnen; dann rutschen unaufgelöste Templates durch. Notiz erst öffnen, Obsidian rendern lassen, dann exportieren.

Canvas-Dateien

Obsidian-Canvas-Dateien (.canvas) sind JSON, kein Markdown, und kein Markdown-Konverter fasst sie an. Bei Canvases ist der brauchbare Weg: einen Screenshot des Canvas auf dem gewünschten Zoom-Level machen, ihn als PNG speichern und dieses Bild in eine Wrapper-Markdown-Notiz einbetten, die Sie dann exportieren. Einige Community-Plugins bieten auch direkt eine „Canvas als Bild exportieren"-Funktion an, falls Sie das oft genug brauchen, um die Installation zu rechtfertigen.

Mermaid-Diagramme

Code-Fences mit dem Tag mermaid werden in Obsidian als Diagramme gerendert. Die meisten Online-Markdown-zu-Word-Konverter rendern sie entweder als Bilder (gut) oder lassen sie als Roh-Code stehen (schlecht). MarkFlow rendert Mermaid vor der Konvertierung zu Inline-SVG, das Word als bearbeitbares Bild anzeigt. Unterstützt Ihr Zielkonverter Mermaid nicht, ist die Ausweichlösung, das Diagramm aus Obsidians Ansicht als PNG zu exportieren und den Codeblock durch einen gewöhnlichen Bild-Embed zu ersetzen.

Fußnoten

Gute Nachricht — Obsidians Fußnoten-Syntax ([^1] und die Definition [^1]: text) ist Standard-GFM und konvertiert sauber zu Words eingebauter Fußnoten-Funktion. Keine Vorverarbeitung nötig.

Tags und Frontmatter

YAML-Frontmatter (----Blöcke am Anfang der Notiz) wird von Konvertern in der Regel abgeschnitten. Enthält das Frontmatter Informationen, die Ihr Leser braucht (Autor, Datum, Status), verschieben Sie sie vor dem Export als normalen Absatz in den Body. Inline-Tags wie #project/research überleben meist als reiner Text — in den meisten Fällen okay, in anderen unschön. Mit Suchen-und-Ersetzen entfernen, falls das Word-Dokument von Nicht-Obsidian-Nutzern gelesen wird.

Wann manuelle Konvertierung die Automatik schlägt

Ich bin ehrlich: Für eine einzelne 2-3-Seiten-Notiz mit minimaler Formatierung ist der schnellste Workflow aus Obsidians Lesemodus kopieren und in Word einfügen. Obsidians Lesemodus rendert HTML, und Word fügt HTML mit überraschender Treue als formatierten Inhalt ein. Tabellen kommen durch, Fett/Kursiv überlebt, Überschriften werden auf Words Heading-Formate abgebildet.

Dieser Paste-aus-dem-Lesemodus-Ansatz scheitert an drei Dingen:

  1. Bilder — sie werden als verlinkte Verweise auf Dateien in Ihrem Vault eingefügt, die in dem Moment brechen, in dem die Datei Ihren Rechner verlässt
  2. Codeblöcke — die Syntaxhervorhebung geht verloren, die Monospace-Schrift ist inkonsistent
  3. Callouts und Mermaid — brechen genauso wie bei einem Standard-Export

Also: kurze Notizen ohne Code oder Bilder → einfügen. Alles Längere oder Technische → der 4-Schritt-Workflow oben.

Fehlerbehebung: Was tun, wenn Dinge brechen

Das sind die Fehlerbilder, die ich am häufigsten sehe. Für einen breiteren Überblick deckt der Leitfaden zur Markdown-Konvertierungs-Fehlerbehebung 15 typische Konvertierungsprobleme im Detail ab.

Bilder fehlen in der Word-Datei. In neunzig Prozent der Fälle ist das ein Pfad-Problem. Prüfen Sie die .md-Quelle — sind die Anhang-Pfade einfache Dateinamen (image.png) oder komplexe Pfade (../../99 Attachments/My Folder/image.png)? Flach klopfen.

Tabellen werden zu einem einzeiligen Brei. Ihre Quelle nutzt Obsidians Legacy-Tabellenformat oder hat inkonsistente Pipe-Zeichen. Öffnen Sie die .md in einem einfachen Texteditor und stellen Sie sicher, dass jede Zeile dieselbe Zahl an Pipes hat. Die Header-Trennlinie muss passen: | --- | --- |.

Codeblöcke verlieren ihre Sprachfarbe. Prüfen Sie, ob Ihre Fences direkt nach den öffnenden drei Backticks ein Sprach-Tag enthalten (z. B. python, js, bash). Konverter nutzen dieses Tag, um Syntaxhervorhebung anzuwenden; Fences ohne Tag landen standardmäßig im Fließtext.

Wikilinks erscheinen nach dem Export immer noch als [[Note Name]]. Die Vorverarbeitung ist nicht gelaufen oder hat diese Datei nicht erfasst. Vergewissern Sie sich, dass Use [[Wikilinks]] in den Einstellungen ausgeschaltet ist, und lassen Sie das in Schritt 2 installierte Konvertierungs-Plugin gezielt gegen die betroffene Datei laufen — die meisten lassen sich auf eine einzelne Notiz einschränken statt auf den ganzen Vault.

Formeln erscheinen als Roh-LaTeX. Der Konverter unterstützt kein Math-Rendering. Entweder Konverter wechseln oder die gerenderte Gleichung in Obsidian screenshotten und als Bild einbetten — unschön, aber verlässlich.

Ein realistischer Workflow für Teams

Wenn Sie der einzige Obsidian-Nutzer in einem Team sind, das Word-Dateien braucht, bauen Sie einen wiederholbaren Prozess statt eines einmaligen Export-Skripts. Die Version, die ich in kollaborativen Projekten nutze:

  1. Im Vault einen dedizierten Ordner Exports/ für Notizen pflegen, die für Word bestimmt sind
  2. In diesem Ordner von Anfang an Standard-Markdown-Links verwenden ([text](note.md)) statt Wikilinks — spart Vorverarbeitung
  3. Wöchentlich eine Batch-Konvertierung für alle geänderten Notizen laufen lassen
  4. Die DOCX-Ausgaben in einem geteilten Laufwerk ablegen, nicht im Vault

Das Ziel ist, Ihren Denk-Raum (den Haupt-Vault mit all seiner Obsidian-spezifischen Power) von Ihrem Liefer-Raum (dem Exports/-Ordner, der Standard-Markdown spricht) zu trennen. Das Refactoring zu dieser Aufteilung hat mich beim ersten Mal eine Stunde gekostet und spart mir seither jeden Monat Stunden.

Falls Sie von der anderen Seite kommen — Sie schreiben in Markdown und sind neugierig, die Grundlagen richtig zu machen — deckt der Leitfaden wie man in Markdown schreibt die Grundlagen ab, die jeden Export geschmeidiger machen. Und für einen genaueren Blick auf die Konvertierungsseite der Pipeline führt die komplette Markdown-zu-Word-Anleitung durch die Konverter-Funktionen, die bei komplexen Dokumenten zählen.

Abschließende Gedanken

Obsidians eigentliche Stärke sind seine nicht-standardisierten Features — die Wikilinks, die Callouts, die dynamischen Abfragen, die einen Vault lebendig wirken lassen. Export nach Word heißt, den größten Teil davon aufzugeben. Der Trick ist, aufzuhören, dagegen anzukämpfen: Akzeptieren Sie, dass die Word-Version eine abgeflachte Repräsentation sein wird, verarbeiten Sie entsprechend vor und nutzen Sie Words Styling-Werkzeuge, um Politur dort wiederherzustellen, wo sie zählt.

Sobald die Vorverarbeitungs-Gewohnheit sitzt, braucht die ganze Pipeline etwa fünf Minuten pro Notiz. Das ist der Unterschied zwischen „Mache ich später" und dem Dokument, das heute tatsächlich rausgeht.

#Obsidian to Word#Obsidian#Markdown to Word#Knowledge Management#Documentation

Finden Sie dieses Tool nützlich? Helfen Sie uns, es zu verbreiten.