Markdown
Convertir Markdown a HTML, con vista previa en vivo
Escribe a la izquierda y ve el resultado a la derecha mientras escribes, con los dos paneles sincronizados. Al terminar, tres salidas distintas: el HTML limpio para tu gestor de contenidos, el HTML con estilos dentro para un correo, y el camino inverso —pegas HTML y sale Markdown legible—.
Tu borrador no sale de esta página: se convierte aquí dentro.
Por qué importa que esto no se suba
Lo que se pega en un editor de Markdown casi nunca es texto público: es un borrador sin publicar, la documentación interna de un producto, las notas de una reunión o el contenido de una web que todavía no existe. Enviar eso al servidor de un desconocido para que le ponga unas etiquetas es un intercambio malo. Aquí no hay a dónde enviarlo: el motor que analiza el Markdown y el que limpia el HTML se descargan a tu navegador y trabajan dentro de él.
Cómo funciona, en 3 pasos
-
Escribe o pega tu Markdown
La vista previa de la derecha se actualiza sola mientras escribes, y los dos paneles se desplazan a la vez. La barra de arriba tiene los formatos con sus atajos, y el tabulador sangra en vez de saltarse de campo.
-
Elige la salida que necesitas
HTML limpio para un gestor de contenidos, HTML con estilos en línea para un correo, o la conversión inversa si lo que tienes es HTML. Cada una con su botón de copiar.
-
Llévatelo
Copia al portapapeles, descarga en
.mdo en.html, o exporta la vista previa a PDF. Abajo, el recuento de palabras y el tiempo de lectura.
Para qué la usa la gente
- Publicar un artículo escrito en MarkdownLo escribiste en tu editor y el blog pide HTML. Copias el HTML limpio y lo pegas, sin estilos que peleen con la plantilla del sitio.
- Maquetar un correo o un boletínLas plataformas de correo descartan las hojas de estilo. El HTML con estilos en línea llega con el formato puesto dentro de cada etiqueta.
- Rescatar un documento de WordTe pasan un documento maquetado y lo quieres en Markdown para el repositorio. Pegas el HTML y sale limpio, con las listas reconstruidas.
- Escribir un READMEVes cómo va a quedar antes de subirlo, con las tablas, las listas de tareas y los bloques de código resaltados.
- Sacar el texto de una página webCopias un artículo y en vez de un amasijo de contenedores y clases te llevas el contenido en Markdown, listo para reutilizar.
- Entregar un documento en PDFEscribes en Markdown, que es rápido, y exportas la vista previa a un PDF con texto de verdad, no una imagen.
Las tres salidas, y por qué no vale la misma para todo
Casi todos los conversores dan una sola salida de HTML y ya. El problema es que el HTML que sirve para un sitio web no sirve para un correo, y quien intenta usar el mismo en los dos sitios acaba con un boletín sin formato y sin entender por qué.
El HTML limpio es semántico y no lleva ni un atributo de estilo: solo <h2>, <p>, <ul>, <strong>, <table>. Es lo que se pega en WordPress, en un gestor de contenidos o en una plantilla, donde el diseño lo pone la hoja de estilos del sitio y meter estilos propios solo estorba. Con la casilla de «documento completo» sale además envuelto en su estructura de página, con codificación y una hoja de estilos sobria, listo para guardar como archivo suelto.
El HTML con estilos en línea lleva el aspecto escrito dentro de cada etiqueta. Es feo de leer y es exactamente lo que hace falta para el correo: Gmail elimina las etiquetas de estilo del encabezado antes de mostrar el mensaje, y lo mismo hacen muchas plataformas de boletines, los campos de descripción de producto de las tiendas y algunos gestores de tareas. Los estilos que se usan son de los que el correo entiende —tipografías, tamaños, márgenes, bordes—; nada de rejillas ni de cajas flexibles, que en el correo no funcionan.
Y la conversión inversa es el otro camino, del que se habla justo debajo porque tiene su propia miga.
Convertir HTML a Markdown: lo que casi nadie hace bien
Es la mitad de las búsquedas y la mitad de los resultados decepcionan, siempre por lo mismo: hacen una transcripción literal de cada etiqueta en vez de quedarse con el contenido.
El HTML que la gente pega de verdad no es HTML limpio. Es esto:
- Lo que copia Microsoft Word, con cientos de atributos de estilo propios de Office, etiquetas de su espacio de nombres, comentarios condicionales y —lo peor— listas que no son listas: párrafos sueltos con una viñeta escrita a mano dentro, que una transcripción literal convierte en párrafos con un carácter raro delante.
- Lo que copia Google Docs, que envuelve el documento entero en una etiqueta de negrita con un identificador interno; si no se desenvuelve, sale todo el texto en negrita.
- Lo que se copia de una página web, con sus contenedores anidados, sus clases, sus atributos de datos y sus rastreadores colgando de los enlaces.
Aquí el HTML pasa primero por una limpieza y solo después se convierte. Se tiran los estilos, los espacios de nombres y los comentarios; se quitan los elementos que no aportan contenido; se reconstruyen las listas falsas de Word agrupando los párrafos consecutivos que llevan viñeta o numeración en una lista de verdad; se desenvuelve el envoltorio de Google Docs; se normalizan las etiquetas de presentación a las semánticas —<b> pasa a <strong>, <i> a <em>—; y se colapsan los contenedores vacíos que quedan al quitar todo lo anterior. Cuando se detecta de dónde venía el HTML, la herramienta te lo dice.
Si además lo que arrastras es un pegado sucio de un PDF con los saltos de línea partidos por la mitad, el sitio tiene un limpiador de texto aparte pensado justo para eso.
Qué admite: Markdown extendido, no el de 2004
La base es CommonMark, la especificación que fija todos los casos raros que el Markdown original dejaba al criterio de cada programa. Encima van las extensiones de GitHub Flavored Markdown que ya nadie considera opcionales —tablas, listas de tareas, texto tachado, enlaces automáticos— y las notas al pie, que no están en GitHub pero sí en casi todos los generadores de sitios estáticos.
Los bloques de código se resaltan por lenguaje: basta con escribir el nombre del lenguaje detrás de las tres comillas invertidas de apertura. El resaltador solo se descarga si tu documento tiene algún bloque con lenguaje, así que si escribes texto sin código la página no carga nada de más.
Referencia rápida de sintaxis Markdown
Todo lo que sigue funciona en el editor de arriba. Los bloques marcados como extensión no están en el Markdown original, pero sí en CommonMark con las extensiones de GitHub, que es lo que usan GitHub, GitLab, Reddit, Discord, Obsidian y los generadores de sitios estáticos habituales.
Texto
| Para | Se escribe | Sale | Notas |
|---|---|---|---|
| Negrita | **texto** | texto | También valen dos guiones bajos. |
| Cursiva | *texto* | texto | Un asterisco, o un guion bajo. |
| Negrita y cursiva | ***texto*** | texto | Tres asteriscos. |
| Tachado | ~~texto~~ | Extensión. Dos tildes: con una sola no funciona en ningún sitio. | |
| Código en línea | `código` | código | Si el código lleva comillas invertidas, envuélvelo en dos. |
| Salto de línea | Dos espacios al final | Línea nueva | O una etiqueta <br>, que se ve más. |
| Párrafo nuevo | Una línea en blanco | Párrafo | Un solo salto no crea párrafo. |
| Escapar un símbolo | \*no es cursiva\* | *no es cursiva* | La barra invertida quita el significado especial. |
Estructura
| Para | Se escribe | Notas |
|---|---|---|
| Títulos | # Título 1 · ## Título 2 · ### Título 3 | Hasta seis almohadillas. Deja un espacio después. |
| Cita | > texto citado | Se anidan poniendo >>. |
| Lista con viñetas | - elemento | También valen * y +. Sangra dos espacios para anidar. |
| Lista numerada | 1. elemento | Los números no tienen que ir en orden: se renumeran solos. |
| Lista de tareas | - [x] hecho · - [ ] pendiente | Extensión. La x puede ir en mayúscula. |
| Línea separadora | --- | Tres guiones en una línea sola. |
| Bloque de código | ```js … ``` | El nombre del lenguaje activa el resaltado. |
| Bloque sangrado | Cuatro espacios | Alternativa antigua; sin resaltado por lenguaje. |
Enlaces, imágenes y tablas
| Para | Se escribe | Notas |
|---|---|---|
| Enlace | [texto](https://ejemplo.com) | Con título: [texto](url "título"). |
| Enlace automático | <https://ejemplo.com> | Extensión: una dirección suelta también se enlaza sola. |
| Enlace por referencia | [texto][id] y abajo [id]: https://… | Útil cuando la misma dirección se repite. |
| Imagen |  | Igual que un enlace, con una exclamación delante. |
| Nota al pie | texto[^1] y abajo [^1]: la nota | Extensión. La numeración y los enlaces de vuelta se generan solos. |
| Tabla | | A | B || --- | --- || 1 | 2 | | Extensión. Las columnas no tienen que quedar alineadas en el texto. |
| Alinear una columna | | :--- | :---: | ---: | | Izquierda, centro y derecha, en la fila de guiones. |
| HTML en línea | <sub>abajo</sub> | Lo que Markdown no cubre se escribe en HTML y pasa tal cual. |
Atajos de teclado del editor
| Atajo | Hace | Atajo | Hace |
|---|---|---|---|
Ctrl + B | Negrita | Ctrl + 1 … 3 | Títulos 1 a 3 |
Ctrl + I | Cursiva | Ctrl + Mayús + X | Tachado |
Ctrl + K | Enlace | Ctrl + Mayús + L | Lista con viñetas |
Ctrl + E | Código en línea | Ctrl + Mayús + O | Lista numerada |
Ctrl + Mayús + E | Bloque de código | Ctrl + Mayús + T | Lista de tareas |
Ctrl + Mayús + Q | Cita | Tab | Sangra dos espacios |
En un Mac, Ctrl es ⌘. Los botones de formato funcionan como interruptor: si el texto seleccionado ya lleva el formato, se lo quitan. Y Ctrl + Z deshace como en cualquier campo de texto, también lo que hacen los botones.
Preguntas frecuentes
¿En qué se diferencian Markdown, CommonMark y GitHub Flavored Markdown?
Markdown a secas es el original de John Gruber, de 2004: sencillo y con muchos casos sin definir, porque estaba descrito por su programa y no por una especificación. Dos conversores podían dar resultados distintos con el mismo texto y los dos tenían razón.
CommonMark, de 2014, es la especificación que zanjó eso: cuántos espacios sangran una lista, qué pasa con un asterisco dentro de una palabra, cómo se anidan las cosas. GitHub Flavored Markdown es CommonMark más cuatro añadidos muy usados: tablas, listas de tareas, tachado y enlaces automáticos.
Después está el resto: MultiMarkdown y Pandoc añaden notas al pie, listas de definiciones y fórmulas; Obsidian y Notion añaden sus propios enlaces internos; y lo de Slack o Discord se parece a Markdown pero no lo es. Lo que escribas aquí funciona en CommonMark, en GitHub y en los generadores de sitios estáticos habituales.
¿Qué variante usa exactamente esta herramienta?
CommonMark como base, más las extensiones de GitHub —tablas, listas de tareas, tachado y enlaces automáticos— y las notas al pie, que no están en GitHub pero sí en Hugo, Jekyll, Astro, MkDocs y Pandoc.
Es la combinación que hace que un mismo texto se vea igual en un repositorio, en un blog estático y en la mayoría de editores modernos.
¿Por qué el HTML para correo es tan feo?
Porque tiene que serlo. Gmail elimina las etiquetas de estilo del encabezado antes de enseñar el mensaje, y muchas plataformas de boletines y campos de descripción de producto hacen lo mismo. La única forma de que el formato sobreviva es escribirlo dentro de cada etiqueta.
Por eso solo se usan propiedades que el correo entiende de verdad: tipografías, tamaños, márgenes, colores y bordes. Nada de rejillas ni de cajas flexibles, que en muchos clientes de correo no existen. Si lo que buscas es una firma de correo, hay una herramienta específica.
¿Por qué la conversión inversa suele salir mal en otras herramientas?
Porque transcriben cada etiqueta en vez de quedarse con el contenido. El HTML real que la gente pega viene de Word —con cientos de atributos de Office y listas que en realidad son párrafos con una viñeta escrita a mano—, de Google Docs —que envuelve el documento entero en una etiqueta de negrita— o de una página web, con sus contenedores y sus rastreadores.
Aquí se limpia primero y se convierte después: fuera estilos y espacios de nombres, listas de Word reconstruidas, envoltorio de Google Docs desenvuelto, etiquetas de presentación normalizadas a semánticas y contenedores vacíos colapsados. Cuando se reconoce el origen, se te dice.
¿Puedo escribir HTML dentro del Markdown?
Sí: es parte de la especificación y a veces es la única salida. Un salto forzado, un subíndice o una tabla complicada se escriben en HTML porque Markdown no tiene sintaxis para ellos, y pasan tal cual a la salida.
La vista previa sí se sanea antes de pintarse, porque se ejecuta dentro de esta página. Lo que copias o descargas va íntegro, porque es tu contenido y va a tu sitio; y si contiene algo ejecutable, la herramienta te avisa antes.
¿Cómo se calcula el tiempo de lectura?
Palabras entre 200, redondeando hacia arriba, con un mínimo de un minuto. Doscientas palabras por minuto es la velocidad de lectura silenciosa que usan como referencia la mayoría de blogs y gestores de contenido.
Es una estimación para poner un «5 min de lectura» en una cabecera, no una medida: la documentación técnica se lee bastante más despacio, y un texto con mucho código se lee a saltos. Si necesitas un análisis del texto más fino, el contador de palabras entra en más detalle.
¿El PDF sale como texto o como imagen?
Como texto de verdad. Se usa la impresión del propio navegador con una hoja de estilos preparada para papel, en vez de dibujar la página en un lienzo y meter esa imagen dentro de un PDF, que es lo que hacen muchas herramientas.
La diferencia se nota: el texto se selecciona y se copia, el buscador del lector lo encuentra, los enlaces siguen vivos y el archivo pesa una fracción. En el diálogo de impresión, elige «Guardar como PDF» como destino.
¿Se sube a algún servidor lo que escribo?
No. El análisis del Markdown, la vista previa, las tres conversiones y los archivos que descargas se generan dentro de tu navegador. No hay cuentas ni base de datos, y no hay ninguna petición que lleve tu texto a ninguna parte. Con la página ya cargada, desconecta internet y compruébalo: sigue funcionando igual.