JSON vs XML vs YAML: cómo elegir el formato de datos adecuado

Los mismos datos, de tres maneras

Aquí tienes un objeto pequeño representado en los tres formatos. Compararlos lado a lado es la forma más rápida de ver qué sacrifica realmente cada uno.

{
  "user": {
    "name": "Ada Lovelace",
    "roles": ["admin", "editor"],
    "active": true
  }
}

user:
  name: Ada Lovelace
  roles:
    - admin
    - editor
  active: true

<user active="true">
  <name>Ada Lovelace</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

Los mismos tres campos, con cantidades de puntuación muy distintas. Esa diferencia es toda la historia: JSON es el más amigable para las máquinas, YAML es el más amigable para escribirlo a mano, y XML es el más expresivo cuando el documento en sí necesita estructura más allá de simples datos de clave/valor.

Dónde gana JSON

JSON es el formato predeterminado por una razón: se mapea directamente a las estructuras de datos que ya tiene todo lenguaje mainstream (objetos/dicts y arrays/listas), así que analizarlo hace un round-trip hacia tipos nativos sin ambigüedad alguna. No tiene comentarios, ni múltiples formas de escribir el mismo valor, ni sensibilidad a los espacios en blanco — lo cual suena limitante, pero es exactamente lo que lo hace rápido de analizar y seguro de generar mediante programación.

Usa JSON para cualquier comunicación máquina a máquina: cargas útiles de APIs REST y GraphQL, datos pasados entre servicios, cualquier cosa almacenada en una base de datos de documentos (MongoDB, JSONB de PostgreSQL) y cualquier configuración que se lea y escriba principalmente mediante código en lugar de editarse a mano.

Dónde gana YAML

YAML es un superconjunto estricto del modelo de datos de JSON con una sintaxis mucho más amigable para los humanos: sin llaves de cierre que contar, comentarios con # e indentación en lugar de puntuación. Eso es exactamente lo que quieres para archivos que una persona edita directamente y relee en un diff — pipelines de CI (GitHub Actions, GitLab CI), manifiestos de Kubernetes y configuración de aplicaciones.

El contrapunto es que la flexibilidad de YAML es también su mayor trampa: los errores de indentación producen silenciosamente una estructura distinta en lugar de un error de análisis, y valores sin comillas como `no`, `yes`, `on` y las fechas pueden convertirse automáticamente a booleanos o timestamps que no pretendías (el infame 'problema de Noruega', donde el código de país NO se convierte en el booleano false). Pon comillas a tus cadenas cuando haya cualquier ambigüedad.

Dónde gana XML

XML parece una carga heredada junto a JSON, pero hace cosas que ni JSON ni YAML pueden: atributos junto al contenido del elemento, contenido mixto (texto y elementos intercalados, como HTML), espacios de nombres para combinar vocabularios de distintas fuentes, y validación de esquemas madura (XSD) más herramientas de transformación (XSLT) que preceden a JSON por una década.

Por eso XML persiste en dominios centrados en documentos — APIs SOAP, SVG, DOCX/XLSX (que son archivos ZIP llenos de XML) y sistemas empresariales (banca, sanidad, gobierno) con pipelines existentes validados con XSD que nadie va a reescribir. Si tus datos son genuinamente con forma de documento (piensa en 'un párrafo con un span en negrita en medio') y no de registro, XML suele seguir siendo la mejor opción.

Convertir entre formatos

Como los tres describen el mismo modelo de datos de objeto/array/string/number/boolean/null (los atributos y el contenido mixto de XML son lo único que no se mapea limpiamente), convertir entre JSON, YAML y XML suele ser mecánico para cualquier cosa con forma de registro. Las herramientas JSON to YAML, YAML to JSON, JSON to XML y XML to JSON de JsonForge hacen la conversión en el navegador, lo cual es útil cuando migras el formato de un archivo de configuración o necesitas entregar una exportación en JSON a un compañero que solo usa YAML.