Markdown vs HTML para LLM: ~70 % menos tokens y tu HTML no sale del navegador

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 SpecificationSe abre en una pestaña nueva, y las extensiones de tablas, listas de tareas, tachado y autoenlaces están definidas en la GitHub Flavored Markdown SpecSe abre en una pestaña nueva. 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, escribimos un breve documento técnico sintético que explica qué es JSON. El documento contiene un encabezado h2, dos o tres párrafos, una lista con tres viñetas, un bloque de código JSON y una tabla de tres columnas. Después expresamos el mismo contenido de tres maneras: una versión HTML con el patrón de contenedores que verías en una página típica de CMS (clases estilo Tailwind y atributos aria), una versión Markdown con CommonMark más la extensión de tablas de GFMSe abre en una pestaña nueva, y una versión de texto plano sin marcado y con la tabla expresada como filas separadas por tabuladores. Los tres archivos, el script de medición y el JSON de resultados están comprometidos en el repositorio bajo scripts/benchmarks/markdown-vs-html-for-llms/. El texto completo de los tres también aparece al final de esta sección.

Los recuentos de tokens provienen de la biblioteca oficial de OpenAI tiktokenSe abre en una pestaña nueva, versión 0.13.0. cl100k_base es el tokenizador de la familia GPT-3.5 / GPT-4; o200k_base lo usa la familia GPT-4o.

Reducción frente a HTML: Markdown −63,2 % de caracteres, −70,8 % de tokens cl100k, −70,4 % de tokens o200k; texto plano −66,1 % de caracteres, −74,4 % de tokens cl100k, −74,0 % de tokens o200k. La relación caracteres-por-token resulta de 3,50 para HTML, 4,41 para Markdown y 4,63 para texto plano: el HTML cargado de símbolos (<, >, =, ", nombres de atributos) penaliza de forma medible la eficiencia del tokenizador. Los tokenizadores de Claude y Gemini difieren en sus valores absolutos, pero la dirección del impuesto por contenedores es la misma para cualquier tokenizador BPE.

Estos son números para un documento sintético concreto. La web es más desordenada, y las mediciones externas sobre páginas reales informan brechas más marcadas:

• El benchmark de Web2MDSe abre en una pestaña nueva: reducción promedio del 87,5 % de tokens en seis tipos representativos de páginas; en un artículo de 3.000 palabras, HTML ≈ 8.000 tokens frente a Markdown ≈ 2.800 tokens (-67 %).
• El artículo de Beam.ai de 2026Se abre en una pestaña nueva: 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 ReleasePadSe abre en una pestaña nueva: 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.

Documentos de muestra exactos

<section class="prose prose-lg max-w-none">
  <h2 class="text-2xl font-semibold mt-8 mb-4" id="what-is-json">What is JSON?</h2>
  <p class="text-base text-gray-700 leading-relaxed mb-4">JSON (JavaScript Object Notation) is a lightweight, text-based data format used to exchange structured data between systems. It originated in JavaScript but is now language-independent and supported by virtually every modern programming language.</p>
  <p class="text-base text-gray-700 leading-relaxed mb-4">A JSON document is built from a small set of building blocks:</p>
  <ul class="list-disc pl-6 mb-4 space-y-1">
    <li class="text-base text-gray-700">Objects: unordered collections of key-value pairs wrapped in <code class="bg-gray-100 px-1 rounded">{}</code></li>
    <li class="text-base text-gray-700">Arrays: ordered lists of values wrapped in <code class="bg-gray-100 px-1 rounded">[]</code></li>
    <li class="text-base text-gray-700">Primitives: strings, numbers, booleans, and <code class="bg-gray-100 px-1 rounded">null</code></li>
  </ul>
  <p class="text-base text-gray-700 leading-relaxed mb-4">Here is a minimal example representing a single user record:</p>
  <pre class="bg-gray-900 text-gray-100 p-4 rounded overflow-x-auto mb-4"><code class="language-json">{
  "id": 42,
  "name": "Ada Lovelace",
  "active": true
}</code></pre>
  <p class="text-base text-gray-700 leading-relaxed mb-4">The core value types and their typical use cases are summarized below.</p>
  <table class="w-full border-collapse mb-4" aria-label="JSON value types">
    <thead>
      <tr class="border-b border-gray-300">
        <th class="text-left p-2 font-semibold">Type</th>
        <th class="text-left p-2 font-semibold">Example</th>
        <th class="text-left p-2 font-semibold">Typical use</th>
      </tr>
    </thead>
    <tbody>
      <tr class="border-b border-gray-200">
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">string</code></td>
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">"hello"</code></td>
        <td class="p-2">Names, labels, free text</td>
      </tr>
      <tr class="border-b border-gray-200">
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">number</code></td>
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">3.14</code></td>
        <td class="p-2">IDs, counts, measurements</td>
      </tr>
      <tr class="border-b border-gray-200">
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">boolean</code></td>
        <td class="p-2"><code class="bg-gray-100 px-1 rounded">true</code></td>
        <td class="p-2">Flags, feature toggles</td>
      </tr>
    </tbody>
  </table>
  <p class="text-base text-gray-700 leading-relaxed mb-4">JSON is widely used for REST API payloads, configuration files, and persisting application state because it is easy to read, easy to parse, and supported everywhere.</p>
</section>

## What is JSON?

JSON (JavaScript Object Notation) is a lightweight, text-based data format used to exchange structured data between systems. It originated in JavaScript but is now language-independent and supported by virtually every modern programming language.

A JSON document is built from a small set of building blocks:

- Objects: unordered collections of key-value pairs wrapped in `{}`
- Arrays: ordered lists of values wrapped in `[]`
- Primitives: strings, numbers, booleans, and `null`

Here is a minimal example representing a single user record:

```json
{
  "id": 42,
  "name": "Ada Lovelace",
  "active": true
}
```

The core value types and their typical use cases are summarized below.

| Type | Example | Typical use |
| --- | --- | --- |
| string | `"hello"` | Names, labels, free text |
| number | `3.14` | IDs, counts, measurements |
| boolean | `true` | Flags, feature toggles |

JSON is widely used for REST API payloads, configuration files, and persisting application state because it is easy to read, easy to parse, and supported everywhere.

What is JSON?

JSON (JavaScript Object Notation) is a lightweight, text-based data format used to exchange structured data between systems. It originated in JavaScript but is now language-independent and supported by virtually every modern programming language.

A JSON document is built from a small set of building blocks:

Objects: unordered collections of key-value pairs wrapped in {}
Arrays: ordered lists of values wrapped in []
Primitives: strings, numbers, booleans, and null

Here is a minimal example representing a single user record:

{
  "id": 42,
  "name": "Ada Lovelace",
  "active": true
}

The core value types and their typical use cases are summarized below.

Type	Example	Typical use
string	"hello"	Names, labels, free text
number	3.14	IDs, counts, measurements
boolean	true	Flags, feature toggles

JSON is widely used for REST API payloads, configuration files, and persisting application state because it is easy to read, easy to parse, and supported everywhere.

Los tres archivos fuente, el script de medición basado en tiktoken de OpenAI (measure.py) y el JSON de resultados están comprometidos en el repositorio bajo scripts/benchmarks/markdown-vs-html-for-llms/. Ejecuta python3 -m venv venv && ./venv/bin/pip install tiktoken==0.13.0 && ./venv/bin/python measure.py y reproducirás exactamente los números de la tabla anterior.

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 TurndownSe abre en una pestaña nueva 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: tal como cita el análisis de ReleasePadSe abre en una pestaña nueva, una evaluación basada en GPT que se referencia 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. En mayo de 2026, Thariq Shihipar de Anthropic publicó Using Claude Code: The Unreasonable Effectiveness of HTMLSe abre en una pestaña nueva, argumentando 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 TurndownSe abre en una pestaña nueva 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.