Markdown vs HTML para LLM: tokens, precisión y conversión sin subir datos

Pegar una página web en bruto en ChatGPT, Claude o Gemini funciona, pero casi siempre lo pagas dos veces: en tokens y en calidad de la respuesta. El HTML que copiaste está lleno de div contenedores, atributos class, scripts en línea y píxeles de seguimiento, nada de lo cual necesita el modelo para entender el contenido. Markdown elimina todo eso y le deja al modelo solo la estructura y el texto.

Esta guía compara Markdown y HTML como formatos de entrada para un LLM con cifras medidas, enumera los casos en los que HTML sigue siendo la elección correcta y muestra un proceso de conversión que se ejecuta en el navegador y no sube tu HTML interno a un servidor de terceros.

Respuesta rápida

Para la entrada de un LLM, prefiere Markdown. Usa aproximadamente entre un tercio y una décima parte de los tokens del HTML equivalente, y los benchmarks externos muestran mayor precisión en tablas, listas y bloques de código. Pega tu HTML en HTML a Markdown y copia el resultado en tu prompt. La conversión se ejecuta por completo en tu navegador: el HTML que pegas no se sube a FormatArc ni a ningún servicio de terceros.

Cómo leen los formatos los LLM

Los LLM no "ven" el HTML renderizado como lo hace un navegador. Procesan el código fuente en bruto como un flujo de tokens. Cada corchete angular, nombre de clase y estilo en línea consume tokens de la misma ventana de contexto en la que tiene que caber tu contenido real.

De esto se derivan dos consecuencias:

• Una página HTML cargada de contenedores deja menos espacio para instrucciones, ejemplos y la respuesta del asistente.
• El ruido dentro del código fuente (class="text-base text-gray-700", atributos data-*, fragmentos de analítica) puede distraer al modelo del contenido que se supone que debe extraer o reescribir.

Markdown codifica la misma estructura (encabezados, listas, enlaces, código) con uno o dos signos de puntuación por elemento en lugar de etiquetas de apertura y cierre. El resultado es más corto y más coherente con los patrones que los LLM ven en sus corpus de entrenamiento: los archivos README de GitHub, los sitios de documentación, las publicaciones de Stack Overflow y los hilos de foros están escritos predominantemente en Markdown.

La razón estructural por la que Markdown es más liviano es el propio modelo de etiquetas. En el HTML que realmente copias de una página (DOM serializado o salida de un CMS), la mayoría de los elementos contenedores llegan como un par de etiquetas emparejadas (<p>...</p>, <li>...</li>, <td>...</td>, <div>...</div>), de modo que el coste del marcado se paga dos veces por elemento: una para abrir y otra para cerrar. (Técnicamente, HTML permite omitir algunas de estas etiquetas de cierre, pero la serialización del DOM renderizado y los motores de plantillas las emiten de todos modos, que es lo que pegas.) El anidamiento multiplica esto: una lista dentro de una celda de tabla dentro de una fila apila etiquetas de apertura al entrar y etiquetas de cierre al salir, y cada etiqueta también puede llevar atributos class, id, style y data-* que añaden más caracteres sin aportar el significado que el modelo necesita. Markdown expresa las mismas construcciones como marcadores únicos y sin pareja, colocados una sola vez: # para un encabezado, - para un elemento de lista, | para el límite de una columna de tabla, una línea en blanco para un salto de párrafo. No hay un token de cierre que repetir ni una ranura de atributo que rellenar, así que la sobrecarga por elemento es una pequeña constante en lugar de un par contenedor que crece con los atributos y la profundidad de anidamiento. Esa diferencia es la que cuantifican las mediciones de abajo; la causa es la ausencia de duplicación de etiquetas de apertura y cierre.

Las construcciones en sí están definidas por especificaciones publicadas: la sintaxis básica (encabezados, listas, enlaces, spans de código y código delimitado, párrafos) está estandarizada en la CommonMark Specification, y las extensiones de tablas, listas de tareas, tachado y autoenlaces están definidas en la GitHub Flavored Markdown Spec. Ambos son documentos estables y versionados, lo que en parte explica por qué Markdown es tan coherente en los corpus públicos con los que se entrenan estos modelos.

La mezcla exacta de datos de entrenamiento de cada modelo no es pública, así que no conviene exagerar este punto. Lo que sí es verificable es que Markdown se usa ampliamente en el texto técnico público, y los principales proveedores de modelos recomiendan explícitamente una estructura similar a Markdown en sus guías de prompting; por ejemplo, la documentación de prompting de Claude de Anthropic y la guía de diseño de prompts de Gemini de Google sugieren usar encabezados y listas con viñetas para separar secciones.

Eficiencia de tokens: una comparación medida

Para comparar los formatos de forma justa, toma un documento técnico pequeño pero realista (una introducción del tipo "¿Qué es JSON?" con un párrafo, un encabezado, una lista con viñetas, un bloque de código y una tabla de tres columnas) y exprésalo de tres maneras. La versión HTML usa el patrón de contenedores que verías en una página típica de un CMS. La versión Markdown usa CommonMark más la extensión de tablas de GFM. La versión de texto plano es lo que obtienes con "Copiar como texto sin formato" en tu navegador.

Reducción frente a HTML: Markdown -43 % de caracteres, texto plano -54 % de caracteres. Las estimaciones de tokens usan la regla general de OpenAI según la cual el inglés promedia alrededor de cuatro caracteres por token; los tokenizadores de Claude y Gemini difieren en los detalles, pero las proporciones se mantienen en el mismo rango.

La web es más desordenada que esta muestra. Las mediciones externas sobre páginas reales informan brechas más marcadas:

• La prueba controlada de Web2MD sobre un artículo de 500 palabras: HTML ~2100 tokens frente a Markdown ~700 tokens, una reducción de 3x.
• El artículo de Beam.ai de 2026: una reducción de tokens del 68 % en contenido limpio, de hasta el 87 % en páginas reales con todo el andamiaje del DOM.
• El análisis de ReleasePad: una reducción del 10 al 20 % en listas con viñetas simples, que escala con fuerza a medida que aumenta la densidad de contenedores.

Sea cual sea el benchmark en el que confíes, la dirección es la misma: el HTML paga un impuesto por contenedores que Markdown evita, y ese impuesto se acumula en prompts con mucho contexto, donde quieres encajar varios documentos en una sola ventana.

Privacidad: mantén el HTML sensible fuera de los servicios de terceros

Los argumentos sobre tokens y precisión están muy trillados en otros artículos. El ángulo que la mayoría omite es qué pasa con el HTML de origen durante el paso de conversión.

Muchos conversores en línea de "HTML a Markdown" ejecutan la conversión en un servidor backend. Pegas tu HTML, la página lo envía por POST a una API y el servidor devuelve Markdown. Eso está bien para un fragmento público de Wikipedia. No está bien para:

• Una página de documentación interna exportada desde Confluence o Notion.
• El volcado de HTML de un panel de administración que contiene nombres de clientes.
• El cuerpo de la respuesta de un sitio de staging antes de que se apruebe el texto de marketing.
• El cuerpo de cualquier correo electrónico en HTML con datos personales.

La herramienta HTML a Markdown de FormatArc es una página estática. La conversión a Markdown está implementada en JavaScript que se ejecuta en tu navegador, usando la biblioteca Turndown incluida en la página. El HTML que pegas se analiza localmente; ninguna solicitud de red lleva el HTML de origen a FormatArc ni a ningún servicio de terceros. Puedes verificarlo tú mismo abriendo la pestaña de red de las herramientas de desarrollo del navegador, pegando una cadena identificable de forma única en el panel de HTML, pulsando Run y confirmando que ninguna solicitud saliente contiene tu cadena.

"En el navegador" significa aquí que el HTML de origen no se sube. La página en sí se sigue sirviendo por HTTPS desde una CDN, y es posible que se cargue analítica estándar una vez en la primera visita, pero el documento que conviertes nunca sale de tu equipo.

Calidad de comprensión: tablas, código y listas

El recuento de tokens es la mitad fácil. La calidad de comprensión es la mitad que decide si tu prompt realmente funciona.

Los benchmarks publicados tienden a favorecer a Markdown en tres tareas comunes:

• Extracción de tablas: una evaluación basada en GPT que se cita con frecuencia informa una precisión de ~60,7 % en tablas Markdown frente a ~53,6 % en tablas HTML equivalentes, una brecha de 7 puntos sobre datos subyacentes idénticos.
• Manejo de bloques de código: el código delimitado de Markdown con una indicación de lenguaje (```python) preserva la señal del lenguaje de forma limpia; el HTML suele anidar la indicación de lenguaje dentro de un atributo de clase (<pre><code class="language-python">), que el modelo tiene que extraer del marcado.
• Listas anidadas: la indentación de Markdown ofrece una fuerte pista estructural con bajo coste de tokens. Las cadenas <ul><li><ul><li> de HTML consumen tokens y, en ocasiones, confunden al modelo sobre a qué lista pertenece un elemento hijo.

Nada de esto significa que Markdown sea universalmente más preciso (consulta en la siguiente sección dónde gana HTML), pero para el patrón cotidiano de "resume este artículo", "extrae estos campos" o "reescribe esta sección", los datos de comprensión apuntan en la misma dirección que los datos de tokens.

Dónde HTML sigue siendo la elección correcta

Markdown no siempre es la respuesta. Hay tres escenarios en los que pegar HTML es genuinamente mejor:

Cuando la semántica vive en los atributos

aria-label, role, itemprop, los microdatos y las etiquetas de Open Graph transmiten información que no tiene equivalente en Markdown. Si le pides al modelo que audite la accesibilidad, extraiga metadatos estructurados de productos o verifique el marcado de schema.org, los atributos HTML son el contenido. Eliminarlos con un conversor de Markdown destruye la tarea.

Cuando necesitas el diseño visual, no solo el texto

Los diagramas SVG, los gráficos incrustados, los widgets <iframe> y los atributos de datos personalizados de componentes interactivos sobreviven en HTML y desaparecen en Markdown. Comentarios recientes de ingenieros de Anthropic han argumentado que, para los agentes de IA que producen una salida rica orientada a las personas, el rango expresivo de HTML (diseños con estilo, elementos interactivos, SVG incrustado) vale su mayor coste en tokens. El punto se aplica de forma simétrica: si tu entrada contiene elementos visuales sobre los que el modelo debe razonar, envía HTML.

Cuando el modelo va a renderizar el resultado

Si le pides al modelo que produzca una salida que se va a renderizar de vuelta en un navegador, a veces es más sencillo mantener HTML de extremo a extremo y saltarse el paso intermedio en Markdown. Esto es sobre todo una cuestión de herramientas: Markdown hace bastante bien el viaje de ida y vuelta, así que rara vez fuerza una decisión.

Un flujo de trabajo práctico: de HTML a Markdown listo para un LLM

Para el caso común (tienes una página web o un correo electrónico en HTML y quieres darle a un LLM el contenido sin el impuesto del marcado) aquí tienes el flujo de trabajo que mantiene los datos en local.

Paso 1: obtén el HTML

En Chrome o Firefox, haz clic derecho en la página y elige "Ver código fuente de la página", o usa el panel de elementos de las herramientas de desarrollo y copia el HTML externo del elemento <article> o <main>. Para un correo en HTML, usa "Ver código fuente" en tu cliente de correo.

Si solo necesitas el cuerpo del artículo, copia ese subárbol en lugar de la página entera. Eliminar la navegación, la barra lateral y el pie de página en esta etapa recorta más el presupuesto de tokens que cualquier conversión ingeniosa posterior.

Paso 2: convierte en tu navegador

Pega en HTML a Markdown y pulsa Run. El Markdown aparece en el panel derecho.

Para un recorrido más detallado de la conversión en sí (tablas, rutas de imágenes, casos límite de colspan) consulta la guía de HTML a Markdown. Para la dirección inversa, cuando el LLM responde con Markdown que quieres recuperar como HTML, Markdown a HTML también lo procesa en local.

Paso 3: recorta antes de pegar

Incluso después de la conversión, revisa el Markdown en busca de residuos que no necesitas:

• Enlaces de navegación que se convirtieron en elementos de lista en la parte superior.
• Banners de consentimiento de cookies que aún dejaron un párrafo detrás.
• Bloques de copyright del pie de página.

Dos minutos de recorte manual suelen recuperar más contexto que cualquier paso automatizado adicional.

Paso 4: redacta el prompt con el Markdown limpio

Una plantilla sencilla que funciona para la mayoría de las tareas de extracción:

Below is a documentation page in Markdown.

Task: <one sentence>.
Constraints: <output format, length, etc.>.

---

<paste the cleaned Markdown here>

Los encabezados de Markdown le dan al modelo anclas sólidas a las que referirse en su respuesta ("En la sección 'Sintaxis'..."), lo que mejora la especificidad de la respuesta.

Errores frecuentes al convertir HTML para la entrada de un LLM

Cinco cosas suelen salir mal. Presta atención a estas:

1. Los bloques de código pierden su indicación de lenguaje. <pre><code class="language-python"> debería convertirse en ```python. Algunos conversores descartan la indicación, lo que obliga al modelo a adivinar el lenguaje.
2. Las tablas con colspan o rowspan se colapsan. Las tablas con barras verticales de GFM son estrictamente rectangulares, así que las celdas combinadas se aplanan. Para tablas de datos, considera convertir a través de CSV a Markdown en su lugar; la guía de CSV a Markdown recorre la conversión. Consulta también la chuleta de sintaxis de tablas Markdown y la chuleta de tablas GFM para la alineación y el escape.
3. HTML en línea que se cuela. Tanto CommonMark como GFM permiten HTML en bruto en línea. Si el modelo va a ver <span class="text-red">important</span> en tu "Markdown", eso vuelve al cubo del impuesto por contenedores. Usa un conversor que emita Markdown puro en los casos que pueda, y reserva el HTML en bruto solo para las construcciones (notación matemática, tablas complejas) que realmente lo necesiten.
4. Rutas relativas de imágenes y enlaces. <img src="/images/foo.png"> se convierte en ![](/images/foo.png), que el LLM no puede obtener. O reescribe las rutas a URL absolutas, o indica en el prompt que las imágenes no están disponibles.
5. Desajuste entre CommonMark y GFM. Las tablas, las listas de tareas, el tachado y los autoenlaces son extensiones de GFM. Si tus herramientas posteriores son CommonMark estricto, esas funciones no se renderizarán. Consulta CommonMark vs GFM para conocer los límites.

Comparación de formatos de un vistazo

Para los impacientes, aquí está la matriz de decisión:

Para la mayoría de los prompts cotidianos ("resume este artículo", "extrae estos campos", "reescribe en lenguaje sencillo") Markdown es la opción correcta por defecto.

Preguntas frecuentes

¿Debería usar Markdown o texto plano para el contexto de ChatGPT?

Markdown si la fuente tiene alguna estructura (encabezados, listas, tablas, código). Texto plano si es genuinamente prosa sin formato. El texto plano es el más económico, pero descarta las pistas estructurales que ayudan al modelo a navegar contextos más largos.

¿Claude entiende mejor Markdown que HTML?

Claude maneja ambos. La guía de prompting de Anthropic recomienda encabezados y listas al estilo Markdown para separar las secciones del prompt, y además fomenta el uso de etiquetas XML (<instructions>, <context>) como límites entre las partes del prompt. Markdown sigue ganando en eficiencia de tokens para el contenido en sí; XML resulta útil alrededor del contenido como andamiaje.

¿Y JSON o XML para el contexto estructurado?

Usa JSON cuando los datos sean naturalmente tabulares o con forma de registros (respuestas de API, configuración). Usa XML cuando quieras límites explícitos entre las secciones del prompt; la documentación de Anthropic usa este estilo. Para la prosa, ninguno supera a Markdown en coste de tokens.

¿Cómo convierto una URL directamente a Markdown listo para un LLM?

No existe una forma totalmente del lado del cliente para obtener una URL arbitraria desde una página estática (CORS lo bloquea). Guarda la página localmente primero (Cmd/Ctrl-S, o copia el código fuente desde las herramientas de desarrollo) y pega el HTML en HTML a Markdown. La conversión en sí se mantiene en tu navegador.

¿La conversión de FormatArc es realmente solo en el navegador?

Sí, para el paso de conversión. El HTML que pegas lo analiza la biblioteca JavaScript Turndown incluida en la página, y no se envía ninguna solicitud que contenga la fuente. La página en sí se carga desde una CDN por HTTPS y puede hacer llamadas de analítica estándar en la primera visita, pero el HTML que pegaste no forma parte de ninguna solicitud saliente.

Para terminar

Para el contexto de un LLM, Markdown supera a HTML en los dos ejes que importan: cuesta menos tokens y permite que el modelo se centre en el contenido en lugar de en el andamiaje. La proporción exacta depende de la página de origen, pero la dirección es coherente en todos los benchmarks publicados.

Si el HTML de origen es sensible (documentos internos, datos de clientes, borradores no publicados) el paso de conversión en sí importa. HTML a Markdown se ejecuta localmente en tu navegador, así que la fuente nunca llega a un servidor de terceros.

Para la dirección inversa, consulta Markdown a HTML y la guía de Markdown a HTML. Para problemas específicos con las tablas de tu Markdown convertido, la chuleta de sintaxis de tablas Markdown cubre el escape, la alineación y los errores comunes.