Exportar Obsidian a Word: la guía práctica para 2026

Vault de Obsidian convertido a un documento de Microsoft Word conservando el formato

Si vives dentro de Obsidian, ya conoces el problema. Pasaste tres meses construyendo una nota de investigación repleta de sintaxis específica de Obsidian — cosas como:

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

Y entonces un compañero te pide la versión en Word — y cada uno de esos elementos no estándar se rompe.

Me topé con este problema la primera vez que tuve que entregar una investigación técnica de 40 páginas a un stakeholder que ni se acercaba a Obsidian. Lo que en el vault se veía pulido salió como un amasijo de corchetes literales y huecos de imágenes huérfanas en Word. Tras pelearme con aquella conversión — y con varias más desde entonces — he dado con un flujo de trabajo que aguanta. Esta guía lo documenta: el paso de preprocesamiento que casi todo el mundo se salta, las tres peculiaridades de Obsidian que de verdad importan y qué hacer cuando las imágenes o los callouts se niegan a cooperar.

Por qué el Markdown de Obsidian no es portable (y qué se rompe)

Obsidian guarda las notas como archivos .md en texto plano, y por eso la gente asume que exportar a Word es trivial. No lo es — porque Obsidian extiende el Markdown estándar con funciones que ningún convertidor genérico entiende.

Comparación lado a lado entre la sintaxis específica de Obsidian y la salida en CommonMark estándar

Estas son las cuatro extensiones responsables de casi todas las exportaciones fallidas:

Sintaxis de Obsidian	Qué significa	Qué pasa en Word
`[[Project Plan]]`	Wikilink a otra nota	Aparece como texto literal `[[Project Plan]]`
`![[diagram.png]]`	Adjunto embebido	Aparece como texto literal, la imagen se pierde
`> [!warning] Title`	Bloque de callout	Se renderiza como una cita plana, la cabecera desaparece
Bloques de código `dataview`	Resultado de consulta dinámica	Exporta la consulta cruda, no la tabla renderizada

Los convertidores de Markdown estándar — Pandoc, la mayoría de herramientas online — tratan [[...]] como texto literal y ![[...]] como un token desconocido. La vista renderizada que ves en Obsidian es una previsualización, no la fuente. Esa distinción es la raíz de casi toda la frustración del tipo "¿por qué se rompió mi exportación?".

Hay también un problema más sutil: las rutas de los adjuntos. Obsidian resuelve ![[image.png]] rastreando tu vault en busca de un archivo que coincida, sin importar la carpeta. El Markdown estándar necesita una ruta relativa explícita. Si tu vault guarda los adjuntos en 99 Attachments/ y tu nota vive en 10 Projects/, el enlace a la imagen hay que reescribirlo antes de que cualquier convertidor pueda encontrarlo.

Antes de exportar: el paso de preprocesamiento que te salva

La mayor mejora de fiabilidad en mi flujo vino de dedicar una pasada de preprocesamiento de 5 minutos antes de ejecutar ningún convertidor. Sáltatela y te vas a pasar 30 minutos limpiando el archivo de Word después.

Estructura de un vault de Obsidian mostrando la carpeta de notas y la carpeta de adjuntos

Paso 1: revisa la configuración de adjuntos

Abre Settings → Files and links. Fíjate en dos valores:

Default location for new attachments — dónde aterrizan las nuevas imágenes o PDF.
New link format — cómo escribe Obsidian las rutas (Shortest path when possible, Relative path to file o Absolute path in vault).

Si está en Shortest path when possible (el valor por defecto de Obsidian), tu exportación se romperá en cualquier nota cuyos adjuntos no estén en la misma carpeta. Antes de exportar, cambia a Relative path to file. Esta opción solo afecta a partir de ese momento — los enlaces existentes conservan su formato antiguo hasta que los reescribas. El Paso 2 se encarga de esa reescritura.

Paso 2: convierte los wikilinks a enlaces Markdown estándar

Obsidian tiene un interruptor para esto: Settings → Files and links → Use [[Wikilinks]] → OFF. Cuando está apagado, los enlaces nuevos se escriben como [Note Name](Note-Name.md). Pero esto solo afecta a los enlaces nuevos.

Para convertir los [[wikilinks]] ya existentes en una nota, tienes dos opciones:

Manual para exportaciones pequeñas — Cmd/Ctrl+F dentro de la nota, busca cada [[ y reescríbelo. Vale para una nota de 5 páginas.
Community plugin para vaults grandes — abre Settings → Community plugins y busca términos como "link converter" o "markdown links". Varios plugins del ecosistema convierten wikilinks (y adjuntos embebidos ![[...]]) a sintaxis Markdown estándar en lote, sobre el archivo actual o una carpeta entera. Elige uno con actualizaciones recientes y un número de instalaciones que te dé confianza.

Tras la reescritura, tus adjuntos embebidos se verán como ![image.png](path/to/image.png). Revisa la salida — si tu carpeta de adjuntos tiene espacios, codifícalos en URL (My%20Vault/attachment.png) o el convertidor dejará caer la imagen en silencio.

Paso 3: decide qué hacer con los callouts

Los callouts de Obsidian (> [!note], > [!warning], etc.) son valiosos dentro del vault, pero no tienen equivalente en Word. Tienes tres opciones, ordenadas por esfuerzo:

Aceptar la degradación — se renderizarán como citas planas. Se pierde el tipo de callout (note/warning/tip), pero el contenido sobrevive. Aceptable para la mayoría de entregas.
Reescribir los importantes — sustituye > [!warning] Critical por > **⚠️ Critical:** antes de exportar. Legible en ambos sitios.
Posprocesar en Word — convierte las citas en cajas con estilo usando los Quick Styles de Word. Solo compensa para entregables muy pulidos.

Yo uso la opción 2 para cualquier cosa por debajo del umbral de 20 páginas y la opción 1 para todo lo demás.

Paso 4: exporta los bloques Dataview como contenido estático

Si tu nota contiene consultas Dataview, se exportan como el código de la consulta, no como la tabla resultante. Antes de exportar, ejecuta la consulta en Obsidian, copia la salida renderizada y pégala como una tabla Markdown estática en lugar del bloque de código. Sí, es manual. No, no hay una forma limpia de evitarlo — Dataview se renderiza en el cliente, así que el archivo fuente literalmente no contiene los datos.

El flujo de exportación en cuatro pasos

Diagrama del flujo en cuatro pasos: preprocesamiento del vault, exportación Markdown, convertidor y refinamiento en Word

Una vez hecho el preprocesamiento, la conversión en sí es sencilla.

1. Copia la nota (no exportes en sitio)

Duplica tu nota objetivo y sus adjuntos en una carpeta temporal fuera del vault. No quieres que las ediciones de preprocesamiento (reescrituras de enlaces, sustitución de callouts) contaminen tu vault principal. Yo mantengo una carpeta llamada _export-staging/ en el escritorio para esto.

2. Aplana las rutas de los adjuntos

Mueve todas las imágenes referenciadas a la misma carpeta que el archivo .md y actualiza los enlaces para que sean nombres de archivo simples: ![diagram](diagram.png) en lugar de ![diagram](../../99 Attachments/diagram.png). La mayoría de convertidores sufren con rutas que suben por el árbol de carpetas.

3. Ejecuta el convertidor

Sube el .md preprocesado al convertidor de Markdown a Word de MarkFlow. Entiende GitHub Flavored Markdown (GFM) — incluyendo tablas, listas de tareas y notas al pie — lo que cubre todas las funciones estándar que Obsidian produce después del preprocesamiento. Las imágenes se embeben inline, los bloques de código conservan su resaltado de sintaxis y los encabezados se mapean a los estilos Heading de Word para que el panel de navegación funcione en el DOCX resultante.

Si la nota lleva matemáticas en LaTeX ( $E=mc^2$ o $$...$$), confirma que el convertidor que elijas las preserve como ecuaciones de Word en vez de aplanarlas a texto plano. Para notas con muchas fórmulas — registros de investigación, borradores académicos — esta es la función que decide el éxito o el fracaso. Si Word no es el destino final y solo necesitas un archivo compartible, convertir Markdown a PDF esquiva por completo las rarezas de Word con las ecuaciones.

4. Refina en Word

Abre el DOCX y aplica una plantilla de Word si tienes una. Los estilos de encabezado de Markdown se mapean limpiamente sobre los Heading 1/2/3 integrados de Word, así que reestilar el documento entero es una operación de un clic vía Design → Document Formatting. Revisa tres cosas antes de enviarlo:

Tabla de contenidos — insértala vía References → Table of Contents para verificar que todos los encabezados se hayan recogido correctamente.
Tamaño de las imágenes — Obsidian las muestra al tamaño natural, Word puede inflarlas. Selecciona todo y redimensiona si hace falta.
Hipervínculos — los enlaces externos deberían estar vivos; los [[wikilinks]] internos deberían estar resueltos o eliminados.

Casos particulares propios de Obsidian

Algunos escenarios aparecen con suficiente frecuencia como para tratarlos aparte.

Daily notes y plantillas

Si estás exportando una daily note que usa {{date}} o variables de Templater, la exportación ocurre después de que Obsidian las haya sustituido — así que el .md exportado contiene la fecha real, no el placeholder. No hace falta nada especial. La excepción es si exportas desde el sistema de archivos sin abrir la nota en Obsidian; entonces las plantillas sin resolver se colarán. Abre la nota primero, deja que Obsidian la renderice y luego exporta.

Archivos Canvas

Los archivos canvas (.canvas) de Obsidian son JSON, no Markdown, y ningún convertidor de Markdown los va a tocar. Para los canvas, lo que funciona es hacer una captura del canvas al nivel de zoom que quieras, guardarla como PNG y luego embeberla en una nota Markdown envoltorio que sí exportes. Algunos community plugins también ofrecen exportar el canvas como imagen directamente si lo necesitas hacer lo bastante a menudo como para justificar instalar uno.

Diagramas Mermaid

Los bloques de código cercados con mermaid se renderizan como diagramas dentro de Obsidian. La mayoría de convertidores online de Markdown a Word o los renderizan como imágenes (bien) o los dejan como código crudo (mal). MarkFlow renderiza Mermaid a SVG inline antes de la conversión, y Word lo muestra como una imagen editable. Si tu convertidor no soporta Mermaid, la alternativa es exportar el diagrama como PNG desde la vista de Obsidian y reemplazar el bloque de código por una incrustación de imagen estándar.

Notas al pie

Buenas noticias — la sintaxis de notas al pie de Obsidian ([^1] y la definición [^1]: text) es GFM estándar y se convierte limpiamente a la función nativa de footnotes de Word. Sin preprocesamiento.

Etiquetas y frontmatter

El frontmatter YAML (los bloques --- al inicio de la nota) suele eliminarlo el convertidor. Si el frontmatter contiene información que tu lector necesita (autor, fecha, estado), muévela al cuerpo como un párrafo normal antes de exportar. Las etiquetas inline tipo #project/research suelen sobrevivir como texto plano — lo cual es aceptable en la mayoría de casos, y raro en otros. Haz buscar-y-reemplazar para quitarlas si el documento Word lo van a leer personas ajenas a Obsidian.

Cuándo la conversión manual gana a la automatización

Seré honesto: para una nota suelta de 2-3 páginas con formato mínimo, el flujo más rápido es copiar desde la vista de lectura de Obsidian y pegar en Word. El modo de lectura de Obsidian renderiza HTML, y Word pega HTML como contenido formateado con una fidelidad sorprendente. Las tablas pasan, la negrita y la cursiva sobreviven, los encabezados se mapean a estilos de encabezado de Word.

Este enfoque de "pegar desde la vista de lectura" falla en tres cosas:

Imágenes — se pegan como referencias vinculadas a archivos en tu vault, que se rompen en el instante en que el archivo sale de tu máquina.
Bloques de código — el resaltado de sintaxis se pierde, la fuente monoespaciada es inconsistente.
Callouts y Mermaid — la misma rotura que en una exportación estándar.

Entonces: notas cortas sin código ni imágenes → pegar. Cualquier cosa más larga o técnica → el flujo de 4 pasos de arriba.

Solución de problemas: qué hacer cuando algo falla

Estos son los modos de fallo que veo con más frecuencia. Para una referencia más amplia, la guía de problemas al convertir Markdown cubre 15 problemas de conversión habituales en detalle.

Faltan imágenes en el archivo Word. El 90 % de las veces es un problema de rutas. Revisa el fuente .md — ¿las rutas de adjuntos son nombres simples (image.png) o rutas complejas (../../99 Attachments/My Folder/image.png)? Aplánalas. Esto resuelve alrededor del 80 % de los problemas de imágenes rotas que me he encontrado.

Las tablas salen como un churro de una sola línea. Tu fuente usa el formato de tabla heredado de Obsidian o tiene caracteres pipe inconsistentes. Abre el .md en un editor de texto plano y asegúrate de que cada fila tiene el mismo número de pipes. El separador de cabecera debe coincidir: | --- | --- |.

Los bloques de código pierden el color del lenguaje. Comprueba que los cercados incluyen la etiqueta del lenguaje (por ejemplo, python, js, bash) justo después de los tres backticks de apertura. Los convertidores usan esa etiqueta para aplicar resaltado de sintaxis; los cercados sin etiqueta se quedan en texto plano.

Los wikilinks siguen saliendo como [[Note Name]] tras la exportación. El preprocesamiento no se ejecutó, o no cubrió este archivo. Confirma que Use [[Wikilinks]] está desactivado en ajustes y luego vuelve a pasar el plugin de conversión que instalaste en el Paso 2 sobre el archivo concreto — la mayoría permiten limitar el alcance a una sola nota en vez del vault entero.

Las fórmulas matemáticas aparecen como LaTeX crudo. El convertidor no soporta renderizado de fórmulas. O cambias de convertidor, o haces captura de la ecuación renderizada en Obsidian y la embebes como imagen — feo pero fiable.

Un flujo realista para equipos

Si eres el único usuario de Obsidian en un equipo que necesita archivos Word, monta un proceso repetible en lugar de un script de exportación ad hoc. La versión que uso en proyectos colaborativos:

Mantén una carpeta dedicada Exports/ dentro del vault para las notas destinadas a Word.
En esa carpeta, usa enlaces Markdown estándar desde el principio ([text](note.md)) en vez de wikilinks — te ahorra preprocesamiento.
Ejecuta una conversión por lotes semanal con las notas que hayan cambiado.
Guarda los DOCX resultantes en un disco compartido, no en el vault.

El objetivo es separar tu espacio de pensamiento (el vault principal con todo su poder específico de Obsidian) de tu espacio de entrega (la carpeta Exports/ que habla Markdown estándar). Refactorizar hacia esta separación me llevó una hora la primera vez y me ha ahorrado horas cada mes desde entonces.

Si vienes desde el lado contrario — escribiendo en Markdown y con curiosidad por afinar lo básico — la guía sobre cómo escribir en Markdown cubre los fundamentos que hacen que cualquier exportación sea más suave. Y para mirar más de cerca el lado de la conversión, la guía completa de Markdown a Word recorre las funciones del convertidor que importan en documentos complejos.

Reflexiones finales

La verdadera fortaleza de Obsidian son sus funciones no estándar — los wikilinks, los callouts, las consultas dinámicas que hacen que un vault se sienta vivo. Exportar a Word significa renunciar a la mayor parte de eso. El truco es dejar de pelearse: acepta que la versión en Word será una representación aplanada, preprocesa en consecuencia y usa las herramientas de estilo de Word para reconstruir el pulido donde importa.

Una vez que el hábito del preprocesamiento encaja, toda la tubería te lleva unos cinco minutos por nota. Esa es la diferencia entre "lo hago luego" y enviar el documento hoy.