JSON vs YAML vs CSV vs Markdown: hoja de comparación de formatos de datos

JSON, YAML, CSV y Markdown son cuatro formatos de texto con estructura, pero cada uno se diseñó para un trabajo distinto. Si usas CSV para un archivo de configuración, la estructura queda plana. Si eliges YAML para una respuesta de API, pierdes el rigor que buscabas. Guardar datos tabulares en JSON repite las claves en cada fila. Tratar Markdown como almacén primario te obliga a reconstruir la estructura más tarde. Elegir el formato equivocado se paga en herramientas, validación y horas de desarrollo.

Este artículo es una hoja de referencia de una sola página para responder "¿qué formato debo usar?". Empieza con una matriz de decisión rápida, sigue con una tabla de funciones, soporte de comentarios, ecosistema de parsers, matriz de decisión por caso de uso, errores comunes, elección para contexto LLM y referencias de especificaciones — todo en una pestaña.

Matriz de decisión rápida — elige un formato

Si solo lees una tabla, lee esta.

Versión corta: JSON para intercambio entre máquinas, YAML para configuración editada a mano, CSV para datos tabulares, Markdown para prosa. Luego ajustas en los bordes según las excepciones que vemos abajo.

Pruébalo primero — convierte entre los cuatro formatos en tu navegador

Las diferencias se entienden mejor cuando pones el mismo dato en los cuatro formatos. FormatArc ofrece siete herramientas de navegador para convertir entre los cuatro formatos cubiertos en este artículo. Sin subida, sin ida y vuelta al servidor — los datos que pegas se quedan en tu pestaña.

• JSON Formatter — validar y formatear JSON
• YAML to JSON / JSON to YAML — ida y vuelta entre YAML y JSON
• CSV to JSON — convertir datos tabulares en un array estructurado
• CSV to Markdown — convertir una columna de hoja de cálculo en una tabla Markdown
• Markdown to HTML / HTML to Markdown — convertir entre formatos de documento

Si alguna vez has dudado en pegar datos de producción en una herramienta online que sube los datos a su servidor, revisa ¿Son seguros los convertidores online? para un marco de evaluación de ese riesgo.

Lo que cubre este artículo — y lo que no

Comparamos cuatro formatos: JSON, YAML, CSV y Markdown. Son la combinación más frecuente en desarrollo web moderno, configuración, intercambio de datos y documentación, y coinciden exactamente con las siete herramientas que ofrece FormatArc.

Fuera de alcance, por diseño:

• XML — todavía importante para SOAP, RSS, SVG y Office Open XML, pero rara vez se elige para proyectos nuevos.
• TOML — usado por Cargo y pyproject.toml. Se solapa con YAML y JSON5 en el espacio de configuración y es poco común en trabajo orientado al navegador.
• Parquet — formato binario por columnas para big data. Fuera del alcance de una comparación entre formatos de texto.
• XLSX / ODS — formatos binarios de hoja de cálculo. Solo aparecen a través de su exportación a CSV.

Si quieres una comparación de cinco formatos que incluya XML o TOML, varios artículos competidores lo hacen. El ángulo aquí es distinto: Markdown se trata como ciudadano de primera, porque en 2026 está al lado de JSON y YAML en el flujo diario de cualquiera que escriba APIs, configuraciones, READMEs y prompts para LLM.

El mismo dato en los cuatro formatos

Lado a lado, con dos usuarios, edades y una lista de habilidades, los cuatro formatos muestran su personalidad.

JSON

{
  "users": [
    { "name": "Alice", "age": 30, "skills": ["Python", "Go"] },
    { "name": "Bob",   "age": 25, "skills": ["JavaScript"] }
  ]
}

YAML

users:
  - name: Alice
    age: 30
    skills:
      - Python
      - Go
  - name: Bob
    age: 25
    skills:
      - JavaScript

CSV

CSV no puede expresar anidamiento nativamente, así que skills debe aplanarse. Patrones comunes son unir con un delimitador, expandir en varias columnas o separar en otra tabla. La versión más simple con delimitador:

name,age,skills
Alice,30,Python;Go
Bob,25,JavaScript

Markdown

Markdown es un formato de documento, no de datos. La estructura ocurre a través de la extensión de tablas de GFM.

| name  | age | skills      |
|-------|-----|-------------|
| Alice | 30  | Python, Go  |
| Bob   | 25  | JavaScript  |

La misma información, cuatro formas distintas. JSON es estricto y fácil de parsear. YAML se lee de forma natural. CSV brilla en tablas pero no anida. Markdown se ve bien al renderizar pero pierde la estructura si lo tratas como almacén de datos.

Matriz de funciones por formato

¿Qué puede expresar realmente cada formato?

JSON y YAML comparten el mismo modelo de datos subyacente (objetos, arrays, primitivos), por eso el round-trip entre ambos es directo. FormatArc ofrece YAML to JSON y JSON to YAML en ambas direcciones. Para un análisis más profundo de la comparación de solo dos formatos, ver YAML vs JSON: 7 diferencias.

Matriz de soporte de comentarios

Aquí es donde realmente se decide la elección del formato de configuración. Los estándares y los dialectos divergen.

Los comentarios en JSON surgen a menudo. No están permitidos en JSON estándar y JSON.parse lanza un error. Ver ¿Se pueden escribir comentarios en JSON? para las salidas con JSON5 / JSONC / preprocesamiento.

Comparación del ecosistema de parsers

Cuando recurres a la biblioteca estándar de un lenguaje, ¿qué obtienes?

JSON y CSV vienen en la biblioteca estándar casi en todos lados. YAML y Markdown dependen de librerías externas, aunque las opciones de facto son estables. FormatArc lleva yaml, papaparse, marked, turndown y remark al bundle del navegador, lo que hace posible la conversión sin servidor.

Matriz de decisión por caso de uso

En decisiones reales no preguntas "¿qué formato se lee mejor?", sino emparejas un caso de uso concreto con un formato. Busca tu fila.

Escribir tablas Markdown a mano es tedioso, así que mantén un CSV o JSON como fuente y usa CSV to Markdown para renderizar la tabla. Ver Tablas en README de GitHub desde CSV o JSON para el flujo completo.

Errores comunes de elección

Patrones que se repiten en equipos distintos.

CSV para datos anidados

Meter { "user": { "address": { "city": "Tokyo" } } } en CSV obliga a inventar una convención de aplanamiento que el consumidor tiene que revertir. Si necesitas anidamiento, usa JSON o YAML, o divídelo en un conjunto relacional de CSVs que se unan del lado del consumidor.

Caer en el tipado implícito de YAML

YAML 1.1 convertía no, yes, on, off en booleanos. El famoso "problema de Noruega" es que el código de país NO se convierte silenciosamente en false. YAML 1.2 corrigió partes de esto, pero muchos parsers siguen por defecto en modo compatible con 1.1. Pon entre comillas cualquier cadena que pudiera confundirse con un booleano.

country: "NO"   # seguro — cadena explícita
country:  NO    # podría volverse false en un parser compatible con YAML 1.1

Escribir comentarios en JSON estándar

El settings.json de VS Code permite comentarios, lo que lleva a asumir que el JSON estándar también. No los permite. settings.json es JSONC, un dialecto no estándar. JSON.parse lanza error con cualquier comentario. Si necesitas comentarios, elige JSON5, JSONC o YAML, o quítalos en un paso de preprocesamiento.

Subestimar la variación de dialectos CSV

RFC 4180 es una referencia; el CSV del mundo real es un enjambre de dialectos. Delimitadores (, \t ; |), finales de línea (LF vs CRLF), comillas, BOM, codificación de caracteres, presencia de cabecera y escape de saltos de línea embebidos varían según quién lo escriba. "Es solo CSV" ha costado más horas de depuración que YAML. Verifica los dos extremos con una muestra antes de pasar a producción.

Tratar Markdown como formato de datos legible por máquina

Markdown es un formato de documento. Sus tablas son una extensión de GFM, no parte de CommonMark, y las celdas con pipes o saltos de línea se rompen en renderizadores que no son GFM. Ver Tabla Markdown no se renderiza para los fallos más comunes.

Asumir que las tablas Markdown son CommonMark

No lo son. La sintaxis de tabla es territorio de GFM, MultiMarkdown o Pandoc. Un renderizador en modo CommonMark estricto convierte tu tabla en un párrafo feo. GitHub, Dev.to, Zenn y Qiita son compatibles con GFM; motores de blog antiguos y wikis pueden no serlo. Ver CommonMark vs GFM para el límite.

Elección para contexto LLM

Para entrada de ChatGPT, Claude o Gemini, Markdown es la opción por defecto. Usa aproximadamente entre un tercio y una décima parte de los tokens del HTML equivalente, y los benchmarks externos muestran consistentemente mayor precisión de extracción en tablas, listas y bloques de código. Para salida estructurada de LLM (function calling, modo JSON), JSON es obligatorio. El patrón asimétrico — Markdown a la entrada, JSON a la salida — es el que la mayoría de prompts en producción terminan adoptando.

YAML es arriesgado como entrada de LLM porque su indentación es frágil bajo tokenización y su tipado implícito puede convertir cadenas en booleanos. Los números a nivel de token y la ruta de conversión sin subida están detallados en Markdown vs HTML para LLM.

Specs e historia

Tabla de referencia para quienes toman decisiones.

JSON y CSV tienen RFCs estables. YAML y Markdown tienen familias de dialectos vivos (YAML 1.1 vs 1.2; CommonMark vs GFM vs MultiMarkdown vs Pandoc). Verifica siempre el dialecto del consumidor cuando la interoperabilidad importa.

Para los fundamentos de cada formato:

• ¿Qué es JSON? — sintaxis y casos de uso
• ¿Qué es YAML? — sintaxis y casos de uso
• ¿Qué es CSV? — sintaxis y casos de uso

Convierte entre formatos con las siete herramientas de FormatArc

Las siete rutas canónicas de conversión entre los cuatro formatos viven en el navegador en FormatArc. Nada de lo que pegas sale de tu pestaña.

Encadenadas obtienes flujos como "JSON de API a YAML de configuración", "Excel a CSV a tabla Markdown en README", o "HTML de página web a Markdown para un prompt de ChatGPT" — todo en el navegador.

Resumen

La lista final para cuando tienes que elegir rápido.

• Intercambio de datos entre máquinas: JSON
• Configuración editada a mano: YAML
• Datos tabulares: CSV
• Prosa legible por humanos: Markdown
• Entrada LLM: Markdown; salida LLM: JSON

No hay un formato "correcto". Hay el formato que optimiza lo que te importa — legibilidad, rigor, amplitud de parsers, soporte de comentarios, eficiencia de tokens para LLM. Usa las matrices de arriba como tabla de consulta única la próxima vez que empieces un proyecto.

Referencias de specs:

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange FormatSe abre en una pestaña nueva
• YAML 1.2.2 SpecificationSe abre en una pestaña nueva
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesSe abre en una pestaña nueva
• CommonMark SpecificationSe abre en una pestaña nueva
• GitHub Flavored Markdown SpecSe abre en una pestaña nueva