Conversor de Markdown a HTML

Cómo usar este convertidor

1. Pega tu Markdown. La herramienta acepta CommonMark más las extensiones GFM más comunes, tablas, código cercado con indicaciones de lenguaje, tachado, autoenlaces y elementos de lista de tareas.
2. Observa la conversión en vivo. El panel derecho muestra la salida HTML cruda mientras escribes; el panel de vista previa debajo la renderiza visualmente.
3. Copia el HTML. Usa el botón Copiar HTML para obtener la salida lista para pegar en tu CMS, cliente de correo, plantilla de generador de sitios estáticos o en cualquier otro lugar que acepte HTML.

Una breve historia de Markdown

Markdown fue creado por John Gruber, el escritor detrás del weblog Daring Fireball, con retroalimentación sustancial de diseño de Aaron Swartz. El primer lanzamiento público, versión 1.0, fue anunciado en el sitio de Gruber el 9 de marzo de 2004; la versión 1.0.1, el lanzamiento de referencia canónico, siguió el 17 de diciembre de 2004 y sigue siendo la versión enlazada desde daringfireball.net/projects/markdown. Markdown era dos cosas a la vez desde el principio: una sintaxis de formateo en texto plano y el script Perl original que lo convertía a HTML. El objetivo declarado de Gruber era que el texto fuente debería ser legible tal cual, un documento Markdown abierto en un editor de texto plano debería parecer un correo electrónico cuidadosamente formateado, no una sopa de etiquetas. Esa restricción de legibilidad es la línea filosófica que separa Markdown de los formatos basados en XML y de marcado más pesado como LaTeX, y es la razón por la cual cada extensión posterior ha tenido que argumentar por sí misma en términos de cuán mal interrumpe la fuente. Aaron Swartz había escrito anteriormente un marcado ligero relacionado llamado atx (2002), que contribuyó al estilo de encabezado # y ## ahora familiar, a veces todavía llamado «encabezados estilo atx» dentro de las especificaciones de parser.

CommonMark, arreglar la subespecificación

La descripción de sintaxis original de Gruber de 2004 era famosamente informal, un documento en prosa con ejemplos, no una gramática. Dejaba docenas de casos límite sin especificar, y Gruber nunca lanzó un parser de referencia que no fuera su script Perl, cuyo comportamiento era idiosincrásico de maneras que otros implementadores tenían que copiar o anular. El resultado a principios de la década de 2010 fue que GitHub, Reddit, Stack Overflow, Pandoc y el parser Discount C renderizaban la misma fuente Markdown ligeramente diferente. En 2012, el cofundador de Stack Overflow Jeff Atwood y el autor de Pandoc John MacFarlane comenzaron un esfuerzo para escribir una especificación real y comprobable. El proyecto se lanzó públicamente en septiembre de 2014 como «Standard Markdown»; en cuestión de días Gruber se opuso al nombre en correo privado, Atwood escribió una publicación pública explicando el cambio, y el proyecto fue renombrado «CommonMark». El primer lanzamiento numerado llegó el 25 de octubre de 2014. La versión publicada actual es CommonMark 0.31.2, lanzada el 28 de enero de 2024. La especificación CommonMark es inusual en que es ella misma un documento CommonMark, con más de 600 casos de prueba ejecutables en línea; un parser reclama conformidad pasando esas pruebas. GitHub Flavored Markdown (GFM), la especificación formal en la versión 0.29-gfm fechada el 6 de abril de 2019, define cinco extensiones encima de CommonMark: tablas, elementos de lista de tareas, tachado, autoenlaces para URLs simples, y HTML crudo prohibido (una restricción de seguridad que elimina etiquetas peligrosas del HTML suministrado por el autor).

Los principales parsers

marked.js fue creado por Christopher Jeffrey en 2011 y ha sido mantenido por la organización GitHub markedjs desde 2018, un diseño lexer-luego-parser de un solo paso que prioriza la velocidad bruta; ~36k estrellas y el proyecto Markdown más estrellado en GitHub. Es el parser que esta herramienta usa para la conversión. markdown-it fue lanzado en 2014 por Vitaly Puzrin y Alex Kocharin, anunciando 100% conformidad CommonMark con alternancias GFM opcionales más un ecosistema de plugins agresivo (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor y varios cientos más). Es el parser usado por la vista previa Markdown integrada de VS Code, la interfaz web de GitLab y Eleventy. remark / unified.js no es un solo parser sino un framework de transformación de árboles, el colectivo unified define una especificación de árbol sintáctico abstracto llamada mdast (Markdown AST); remark parsea Markdown a mdast, los plugins manipulan el árbol, y remark-rehype convierte mdast a hast (HTML AST) para emisión. Más lento que marked pero vastamente más componible; usuarios notables incluyen Prettier, Gatsby, MDN y el linter de lenguaje inclusivo alex. Pandoc, lanzado por John MacFarlane el 10 de agosto de 2006, es el convertidor universal de documentos, escrito en Haskell, parsea unos 30 formatos de entrada, renderiza en unos 40 formatos de salida; omnipresente en la publicación académica y técnica.

El pipeline MD-a-HTML, mecánicamente

Un parser Markdown típicamente funciona en dos pasadas. El análisis a nivel de bloque divide la entrada en estructuras de bloque, párrafos, encabezados, listas, vallas de código, citas en bloque, reglas horizontales, tablas. Los límites de bloque se determinan por líneas en blanco e indentación; hacerlos correctamente es la mayor parte de lo que hace correcto un parser CommonMark. El análisis inline luego recorre el contenido de cada bloque y coincide con la sintaxis inline: énfasis (*itálica*, **negrita**), enlaces ([texto](url)), vanos de código inline (`código`), imágenes (![alt](url)), tachado (~~texto~~ en GFM), y autoenlaces explícitos (<https://example.com>). El análisis de énfasis inline es la parte más quisquillosa de cualquier especificación Markdown, CommonMark dedica varias páginas de la especificación y docenas de casos de prueba a especificar cuándo *foo*bar* debería producir <em>foo</em>bar* versus *foo<em>bar</em>. El parser luego renderiza cada token como el elemento HTML correspondiente y concatena los resultados. La impresión bonita, indentación y resaltado de sintaxis de bloques de código se superponen por las opciones de renderizado.

¿Por qué convertir MD a HTML en primer lugar?

• Importaciones CMS. Muchos CMS headless (Contentful, Sanity, Wagtail, Ghost) aceptan HTML pero no Markdown. Redactar en Markdown y convertir una vez al momento de publicar mantiene la experiencia de edición agradable.
• Composición de correos electrónicos. Los clientes de correo renderizan HTML; la mayoría no renderiza Markdown. Las plataformas de boletines (Mailchimp, ConvertKit, Substack) típicamente aceptan HTML pegado en su editor. Convierte tu borrador, pega, envía.
• Borradores de publicaciones de blog. Algunas instalaciones antiguas de WordPress sin el plugin Markdown requieren HTML en el cuerpo de la publicación; algunas páginas de tienda Shopify y Webflow toman HTML en sus campos de texto enriquecido.
• Fragmentos de generador de sitios estáticos. Cuando necesitas un trozo HTML inline para un shortcode de Hugo, una plantilla de Eleventy o un archivo MDX de Next.js, convertir Markdown a un solo fragmento HTML es más rápido que luchar con el pipeline de conversión propio del SSG.
• Compartir notas renderizadas. Pegar Markdown «renderizado» en Slack, Notion, Linear, ClickUp u otros destinos de texto enriquecido a veces quiere HTML en el portapapeles en lugar de Markdown crudo.
• Archivar documentación. Almacenar el HTML renderizado junto con la fuente Markdown significa que tu archivo es legible para humanos en un navegador sin un parser, útil para preservación a largo plazo.

Opciones de salida que vale la pena conocer

Diferentes usos posteriores quieren cosas diferentes del HTML convertido. Documento completo vs fragmento. Un documento HTML completo incluye <!DOCTYPE html>, <html>, <head> con metadatos, y un envoltorio <body>, apropiado cuando guardarás el archivo como .html y lo abrirás en un navegador. Un fragmento es solo el contenido del cuerpo, sin envoltorio, apropiado cuando pegarás en un campo CMS que ya provee la estructura del documento. Esta herramienta emite fragmentos por defecto; envuelve con tu propio boilerplate si necesitas un documento completo. Saneamiento. Por defecto los parsers Markdown pasan el HTML crudo sin cambios, así que si tu fuente contiene <script>alert(1)</script>, esa etiqueta script aparecerá en la salida. Para documentos que van a un sistema multiusuario, pasa la salida por DOMPurify (Cure53, comenzado en febrero de 2014) antes de inyectar en el DOM. Para uso personal puntual, la salida cruda está bien. IDs de encabezado. Generar atributos id en encabezados (slugificados del texto del encabezado) te permite construir una tabla de contenidos con enlaces de anclaje. El algoritmo de slug exacto difiere entre plataformas, GitHub usa una regla, MkDocs otra, marked.js una tercera, así que los enlaces de anclaje pueden romperse cuando el contenido se mueve entre sistemas. Saltos de línea duros. CommonMark requiere o dos espacios al final de una línea o una barra invertida para forzar un <br>; algunas plataformas (Discord, issues de GitHub) tratan los saltos de línea simples como saltos. La elección depende del estilo esperado de tu fuente.

Trampas comunes

• Conversión de comillas inteligentes. Algunos parsers (o capas de post-procesamiento como el propio SmartyPants de Gruber) reemplazan las comillas rectas con comillas tipográficas curvas por defecto. Si necesitas comillas rectas preservadas (porque tu salida se analiza como código), verifica que esta transformación esté desactivada.
• Sensibilidad al espacio en blanco del marcador de lista. Mezclar - y * y + en la misma lista, indentar párrafos de continuación de lista menos de lo que el marcador requiere, o poner una línea en blanco entre elementos de lista puede convertir una lista apretada en una lista suelta (cada elemento envuelto en etiquetas <p>). La diferencia visual en la salida es dramática.
• Exceso de celo del autoenlace. El autoenlazado estilo GFM convierte cualquier URL simple en un enlace, que es usualmente lo que quieres, pero puede mutilar URLs que contienen paréntesis (URLs de Wikipedia especialmente) o puntuación al final.
• Tablas que necesitan escape. Los caracteres pipe dentro de las celdas de tabla deben escaparse como \|, de lo contrario se leen como separadores de columna. Atrapa a cualquiera que intente poner un ejemplo de código de una línea dentro de una celda.
• Markdown y HTML mezclados. Markdown fue diseñado para pasar HTML arbitrario, así que dejar caer un <div class="callout"> en un archivo Markdown funciona. Pero en el momento que pones sintaxis Markdown dentro de un bloque HTML, los parsers divergen: CommonMark trata la mayoría de los bloques HTML como opacos; Markdown Extra introdujo markdown="1" para optar al parsing anidado.
• IDs de encabezado entre plataformas. Diferentes algoritmos de slugificación producen diferentes fragmentos de anclaje para el mismo encabezado; los enlaces intra-documento pueden romperse cuando el contenido se mueve entre sistemas.

Esta herramienta vs el visualizador Markdown

Absolutool envía dos herramientas relacionadas que se superponen en el mismo parser. El visualizador Markdown es para edición en vivo, escribe Markdown a la izquierda, ve la salida visual renderizada a la derecha, sin concepto de «la salida HTML». Este convertidor Markdown-a-HTML es para conversión puntual, pega Markdown, copia HTML crudo, pega en tu CMS o cliente de correo. Usa el visualizador cuando estés redactando y necesites retroalimentación visual; usa este convertidor cuando tengas Markdown terminado y necesites HTML que puedas transportar a otro lugar. Ambas herramientas usan marked.js bajo el capó y aceptan el mismo dialecto CommonMark + GFM, así que el comportamiento de conversión es idéntico entre ellos.

Privacidad: por qué el solo-navegador importa aquí

Borradores de escritura no publicada, publicaciones de blog en progreso, documentación interna, entregables de cliente bajo NDA, capítulos de manuscrito, artículos académicos, son exactamente el tipo de texto que no quieres subir a un servicio de terceros. Los convertidores Markdown del lado servidor requieren enviar el documento entero a un endpoint remoto, lo que significa que queda en los logs del servidor, posiblemente en un caché CDN, posiblemente en un pipeline de analítica, posiblemente en una copia de seguridad. Para texto publicado el problema es discutible. Para trabajo de borrador, la arquitectura importa. Esta herramienta ejecuta todo el pipeline en tu navegador vía JavaScript y marked.js. El Markdown nunca cruza la red, verifica en la pestaña Red de DevTools mientras escribes, o desconecta la página (modo avión) después de que cargue y confirma que el convertidor sigue funcionando. Seguro para borradores confidenciales, entregables de cliente, capítulos de manuscrito bajo NDA, memorandos internos o cualquier otra cosa que no querrías que se copiara en el disco duro de un extraño.

Preguntas frecuentes

¿Qué dialecto Markdown soporta este convertidor?

CommonMark con las extensiones GFM más comunes habilitadas, tablas (delimitadas por pipes con alineación : opcional), bloques de código cercados con indicaciones de lenguaje, tachado vía ~~texto~~, autoenlaces para URLs simples, y elementos de lista de tareas vía [ ] y [x]. Encabezados, negrita, itálica, enlaces, imágenes, listas, citas en bloque, reglas horizontales y código inline funcionan todos como esperarías en GitHub. El renderizador es marked.js, el mismo parser que el visualizador Markdown usa.

¿Esto soporta GitHub Flavored Markdown (GFM)?

Sí, tablas con pipes, bloques de código cercados con indicaciones de lenguaje, listas de tareas, autoenlaces y tachado funcionan todos. Si una extensión GFM no se renderiza, verifica que la entrada siga las reglas de sintaxis CommonMark/GFM: líneas en blanco alrededor de elementos de bloque, conteos de backticks coincidentes en bloques de código cercados, exactamente dos espacios al final (o una barra invertida) para saltos de línea duros. La causa más común de «GFM no funciona» es un editor que elimina los espacios al final al guardar, lo que mata la sintaxis de salto duro.

¿La salida se verá igual en GitHub?

El HTML estructural, párrafos, listas, tablas, encabezados, coincidirá para cualquier entrada que sea CommonMark + GFM válido. Dos capas diferirán. GitHub aplica su propio tema CSS y resaltado de sintaxis, así que colores, fuentes y espaciado se verán diferentes. GitHub también superpone post-procesamiento encima de la especificación, atajos de emoji (:smile:), menciones @user, autoenlace de #issue, rutas de imagen relativas al repositorio, que ningún convertidor conforme a la especificación reproduce. El HTML que esta herramienta emite es portable estructuralmente; la apariencia visual depende del CSS en el destino.

¿Debería sanear la salida antes de publicar?

Si la fuente podría incluir contenido proporcionado por el usuario, sí. Los parsers Markdown pasan el HTML crudo sin cambios, así que una fuente que contenga <img src=x onerror="alert(1)"> producirá esa etiqueta en la salida. Para sistemas multiusuario, pasa la salida por DOMPurify (Cure53, febrero 2014, el saneador JavaScript de facto) antes de inyectar en el DOM. Para uso personal puntual donde la fuente es tu propia escritura, esto no es un problema, lo peor que puedes hacer a tu propia página es pegar en tu propio HTML.

¿Puedo obtener un documento HTML completo con head y body?

Actualmente esta herramienta emite solo el fragmento de cuerpo, el Markdown convertido envuelto en etiquetas HTML semánticas pero no en un documento <html>/<head>/<body> completo. Para guardar como un archivo .html independiente, envuelve la salida tú mismo: <!DOCTYPE html><html><head><meta charset="utf-8"><title>...</title></head><body>[fragmento]</body></html>. O usa Pandoc con la bandera --standalone para salida totalmente independiente con CSS dirigido por plantilla.

¿Se envía mi Markdown a algún lugar?

No. La conversión se ejecuta enteramente en tu navegador vía marked.js. El Markdown que pegas nunca cruza la red, verifica en la pestaña Red de DevTools mientras escribes, o desconecta la página (modo avión) después de que cargue y confirma que el convertidor sigue funcionando. Seguro para borradores confidenciales, entregables de cliente bajo NDA, capítulos de manuscrito o cualquier texto que no querrías que se copiara en el disco duro de un extraño.

Herramientas relacionadas