Pega dos documentos Markdown y mira qué cambió línea por línea. Sirve para README, notas de versión, MDX y documentos con frontmatter. El diff se ejecuta en tu navegador.
Una herramienta gratuita y en el navegador para comparar dos documentos Markdown a nivel de texto fuente. Pega un README.md antiguo a la izquierda, el actualizado a la derecha, y cada título, elemento de lista, enlace, bloque de código y celda de tabla que cambió se ilumina. Nada sale de tu equipo.
El diff trabaja carácter a carácter. Markdown es texto plano, así que esta es la primitiva correcta: ves el cambio literal en el origen del documento, no una suposición sobre cómo lo interpretaría un renderizador.
Si ya usas nuestro diff de texto para prosa general, la página de Markdown es el mismo motor con copia enfocada en los casos que aparecen cuando escribes documentación. Para comparar los bloques de frontmatter YAML al inicio de archivos de Jekyll, Hugo o MkDocs, la página de YAML maneja mejor la estructura sensible a la indentación. Datos estructurados estrictos con búsquedas clave/valor van mejor en diff de JSON.
El diff es a nivel de carácter. Tras el diff bruto, una pasada de limpieza semántica desplaza los resaltados para que caigan en palabras completas, elementos de lista y destinos de enlaces, en lugar de partir un `code span` por la mitad o separar el ## inicial de un título. Las inserciones se pintan en verde a la derecha, las eliminaciones en rojo a la izquierda.
Es un diff sobre el texto fuente, no sobre la salida renderizada. Esa es la primitiva correcta para trabajar con Markdown, y pesa más de lo que parece. Dos documentos que renderizan al mismo HTML pueden tener orígenes muy distintos: **negrita** frente a __negrita__, viñetas con * frente a -, sangrías de cuatro espacios frente a una tabulación en una lista anidada. Un renderizador aplana todo eso en la misma salida y perderías la señal. Cuando quieres saber si una persona realmente solo arregló una errata, el diff de fuente es lo que responde la pregunta.
Markdown es además una familia de dialectos. La especificación original de John Gruber (ver daringfireball.net) era deliberadamente laxa, y con el tiempo CommonMark, GitHub Flavored Markdown, Pandoc y MultiMarkdown tiraron cada uno por su lado. Las tablas existen en GFM y Pandoc, pero no en CommonMark. El tachado con ~~ y las listas de tareas con - [ ] son extensiones de GFM. La herramienta de diff no se preocupa por el dialecto; muestra el texto en bruto. El sabor importa cuando empiezas a preguntarte si un párrafo sigue renderizándose bien con el nuevo tema de docs, lo cual es asunto del renderizador, no del diff.
Dos paneles de texto, un diff. Sin registro, sin subida, sin viaje al servidor.
Pega la versión antigua a la izquierda y la nueva a la derecha. O pulsa Subir en cualquier panel para cargar un archivo .md, .markdown o .mdx. El botón Ejemplo rellena ambos lados con un README pequeño para que veas el diff funcionando antes de pegar tu propio contenido.
Un archivo editado en Windows suele tener finales CRLF; uno desde un servidor Linux usa LF. Un diff de caracteres los trata como distintos, lo que puede pintar todas las líneas como cambiadas. Si el diff se ve sospechosamente lleno de rojo y verde, normaliza los dos archivos al mismo final de línea en tu editor antes. VS Code muestra el final activo en la barra de estado inferior.
Las eliminaciones aparecen en rojo a la izquierda, las inserciones en verde a la derecha. Los dos paneles se desplazan sincronizados. Los bloques de frontmatter, las cercas de código, las filas de tabla y los elementos de lista son solo texto para el motor de diff, así que los cambios dentro de ellos salen del mismo modo que los cambios en la prosa. Los contadores de cambios en cada cabecera te dan una medida rápida de cuán pesada fue la edición.
Quieres una lectura rápida de qué cambió en README.md en una rama de PR frente a main, pero no quieres abrir GitHub, pasar la vista previa renderizada y pulsar "Display the source diff" tres menús más abajo. Pega los dos archivos crudos en esta herramienta. Títulos, cercas de código y destinos de enlaces salen claros. Útil cuando el PR también toca cien archivos de fuente y el cambio de docs queda escondido en el ruido.
Las notas de versión pasan por varias ediciones antes de salir. Los borradores se reordenan, se fusionan viñetas, se mueven números de versión. Diff entre el RELEASE_NOTES.md publicado anterior y el nuevo borrador detecta entradas perdidas y duplicados accidentales, algo que la vista renderizada hace mal porque el ojo se desliza sobre líneas parecidas. El diff también facilita verificar que la sección ## Breaking changes realmente creció entre versiones.
Tu equipo escribe docs en Markdown en un repo Git, pero el sitio público lo genera un CMS o un generador estático como MkDocs, Hugo o Docusaurus. A veces la página publicada se desvía del fuente: alguien editó la página en vivo desde la UI del CMS y olvidó subir el cambio, o un paso de CI reescribió el archivo. Exporta la página publicada como Markdown, pégala en un panel, pega el .md del repo en el otro y la desviación queda delante de ti en segundos.
Enviaste una entrada de blog a un editor en Markdown. El editor te devolvió una versión marcada. Un diff entre las dos es bastante más rápido que releer párrafo a párrafo para absorber las correcciones, sobre todo cuando el editor reordenó secciones o reescribió tu intro. Funciona igual de bien para contenido escrito por terceros donde el redactor necesita confirmar qué retoques de estilo sobrevivieron a la edición.
Migrar un sitio en Docusaurus o Astro de .md a .mdx parece una operación nula hasta que descubres que algunos imports se movieron, varios componentes JSX sustituyeron tablas de Markdown plano y unas cuantas cercas de código quedaron envueltas en componentes propios. Diff entre el page.md antiguo y el nuevo page.mdx, archivo a archivo, y las decisiones de la migración se vuelven revisables. El mismo flujo en sentido inverso si decides que MDX fue un error y quieres volver a Markdown plano.
Una hoja breve para los casos límite de sintaxis que esta herramienta saca a la luz con más frecuencia. La columna de dialecto te dice qué sabores soportan realmente cada característica, ya que ahí es donde aparecen la mayoría de las sorpresas entre renderizadores.
| Topic | What this tool does |
|---|---|
| Diferencias entre sabores | Markdown es una familia. CommonMark es la base de hecho. GFM añade tablas, listas de tareas, tachado y autoenlaces. Pandoc y MultiMarkdown añaden notas al pie, listas de definiciones y más. Una misma fuente puede renderizar muy distinto entre ellos. |
| Tablas | Las tablas con tuberías existen en GFM y Pandoc. No forman parte de CommonMark ni del Markdown original. Si un renderizador imprime caracteres | literales en lugar de celdas, el parser es CommonMark estricto y necesitas uno compatible con GFM. |
| Tachado | ~~texto~~ es una extensión de GFM. El Markdown original y CommonMark no lo soportan. Pandoc lo soporta con la extensión strikeout activa. Si tu texto se renderiza con tildes literales, el renderizador no entiende GFM. |
| Listas de tareas | - [ ] pendiente y - [x] hecho son una extensión de GFM. CommonMark las renderiza como viñetas planas con corchetes literales. GitHub, GitLab y la mayoría de los sitios de docs modernos las soportan; los procesadores de Markdown estándar normalmente no. |
| Bloques de código: con cercas frente a indentados | Los bloques de código con cercas (tres comillas invertidas o tildes, con etiqueta de lenguaje opcional) son CommonMark y se soportan en todas partes. La especificación original solo tenía bloques con sangría de cuatro espacios, que siguen funcionando pero no llevan etiqueta de lenguaje. Mezclar ambos en un archivo es legal pero queda confuso. |
| Saltos de línea forzados | Tres opciones: terminar una línea con dos espacios al final, terminar con una contrabarra \ (CommonMark y GFM, no original) o insertar una línea vacía para un salto de párrafo. Los espacios al final son invisibles en la mayoría de editores, por eso los saltos forzados sobreviven a un diff que ningún humano detecta. |
| Frontmatter | YAML entre cercas ---, TOML entre +++ o JSON entre { } al inicio del archivo. No forma parte de la especificación de Markdown pero está por todas partes en Jekyll, Hugo, MkDocs, Docusaurus y Astro. Los renderizadores lo eliminan antes de parsear el cuerpo. |
| HTML en línea | CommonMark permite etiquetas HTML crudas dentro del Markdown. GFM también, pero aplica un saneador de HTML al renderizar en github.com. Algunos generadores estáticos sanean, otros dejan pasar el HTML y unos pocos lo escapan. Los diffs de páginas con bloques <div> o <iframe> incrustados son habituales en auditorías de migración. |
No. La herramienta hace diff sobre el texto fuente del Markdown, no sobre el HTML que produciría un renderizador. Es intencional. Dos documentos pueden renderizar al mismo HTML y aun así tener fuentes con diferencias relevantes, por ejemplo viñetas escritas con * frente a - o negrita con ** frente a __. El diff a nivel de fuente preserva esa señal. Si quieres ver cómo se renderiza el documento, pégalo en tu previsualizador habitual: la UI web de GitHub, VS Code o tu generador estático.
Un diff de HTML renderizado te dice lo que verán las personas lectoras. Un diff de fuente te dice lo que se cambió de verdad en el archivo. Responden preguntas distintas. Para Markdown, el diff de fuente casi siempre es el más útil porque muestra fielmente las ediciones del autor: un nivel de título cambió de ## a ###, una cerca de código cambió de etiqueta de lenguaje, un enlace relativo se volvió absoluto. Si quieres comparación a nivel de HTML, pasa antes ambos archivos por tu renderizador y compara la salida.
El diff en sí no parsea Markdown, así que no le importa el dialecto. Tablas, listas de tareas, tachado y autoenlaces se ven como texto sin más. El sabor importa cuando preguntas si tu documento sigue renderizándose bien. CommonMark es lo más parecido a una especificación base, y GitHub Flavored Markdown es CommonMark más tablas, listas de tareas, tachado y autoenlaces. Elige el que soporte tu renderizador objetivo.
El frontmatter es solo texto al inicio del archivo, delimitado por --- para YAML o +++ para TOML. Generadores estáticos como Hugo, Jekyll y MkDocs lo usan para metadatos de página. El diff trata el bloque como texto cualquiera, así que los cambios en title:, date: o tags: aparecen como cualquier otra línea. Si tu frontmatter es grande y sensible a la indentación, nuestra página de diff de YAML es mejor para ese bloque por separado.
Sí. MDX es Markdown con componentes JSX incrustados, y el JSX es solo más texto desde el punto de vista del diff. Puedes pegar un .mdx en cualquier panel y el diff sacará a la luz cambios en imports, props de componentes y el Markdown alrededor del mismo modo que con .md. Lo único que la herramienta no hará es validar que tu JSX compile; eso es trabajo del compilador de MDX. Para revisar solo las partes JSX como código, pégalas en nuestro diff de texto.
Los finales de línea son caracteres, así que un archivo guardado con CRLF al estilo Windows y otro con LF al estilo Unix saldrán como distintos en cada línea. Si tus paneles parecen llenos de cambios fantasma, esta es casi siempre la causa. La solución es normalizar ambos archivos al mismo final de línea en tu editor antes de pegar; en VS Code el final activo se muestra en la barra de estado inferior y se cambia con un clic. La opción core.autocrlf de Git también puede meter diferencias CRLF inesperadas entre máquinas.
Tu Markdown nunca sale de tu navegador. El editor, el diff y el formateador corren en tu máquina. Sin analítica sobre tu entrada, sin registros, sin viaje al servidor. Para profundizar en el formato, hay material en Wikipedia, con la especificación CommonMark más reciente en spec.commonmark.org/0.31.2 y el sabor de GitHub en github.github.com/gfm.