JSON vs YAML vs XML: sintaxis, usos y cómo convertir entre ellos

JSON, YAML y XML son formatos de texto plano para datos estructurados. Si les das la misma información, los tres la describen fielmente, pero en la práctica cada uno se ha quedado con su propio terreno: JSON en las API, YAML en los archivos de configuración y XML en documentos y sistemas empresariales. Entender por qué te ayuda a elegir bien y a no llevarte sorpresas al convertir.

Los mismos datos en tres formatos

Aquí tienes la definición de un pequeño servicio escrita de tres maneras. Primero, en JSON:

{
  "service": "web",
  "port": 8080,
  "debug": false,
  "tags": ["api", "public"]
}

Lo mismo en YAML:

# web service
service: web
port: 8080
debug: false
tags:
  - api
  - public

Y en XML:

<?xml version="1.0" encoding="UTF-8"?>
<service name="web">
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>api</tag>
    <tag>public</tag>
  </tags>
</service>

Hay diferencias que saltan a la vista:

• JSON usa llaves, corchetes y comillas. Es estricto: no admite comentarios ni comas finales, y las claves siempre van entre comillas dobles.
• YAML se basa en la sangría en lugar de los corchetes y permite comentarios con #. Es el más compacto y el más fácil de leer de un vistazo.
• XML envuelve cada valor en etiquetas de apertura y cierre y puede añadir atributos a los elementos (name="web"). Es el más verboso, pero también el más expresivo.

JSON: el idioma de las API

JSON encaja directamente con los objetos y arrays de casi cualquier lenguaje de programación, y por eso se convirtió en el formato por defecto de las API web. Los analizadores son rápidos, vienen integrados en navegadores y bibliotecas estándar, y la gramática es tan pequeña que hay muy pocas formas de malinterpretar un documento.

Su rigidez es una ventaja para las máquinas y una pequeña molestia para las personas. No puedes dejar un comentario explicando un ajuste, y una sola coma que falte rompe el archivo entero. Por eso JSON funciona mejor cuando lo escribe un programa y lo lee otro: respuestas de API, registros, exportaciones de datos, package.json.

YAML: configuración escrita por personas

YAML se diseñó para que lo escriban y revisen personas. Por eso tantas herramientas DevOps lo eligieron: los manifiestos de Kubernetes, los flujos de GitHub Actions y los archivos de Docker Compose son YAML. Los comentarios, las cadenas multilínea y la ausencia de signos de puntuación hacen que los archivos de configuración largos sean agradables de mantener.

El precio es la sutileza. La sangría tiene significado, así que un espacio mal puesto cambia la estructura. Y YAML deduce los tipos de los valores sin comillas, lo que provoca sus trampas más famosas:

country: NO      # YAML 1.1: false
version: 1.10    # 1.1 (number)
zip: 01234       # 1234 or octal

Con las reglas de YAML 1.1, que muchos analizadores siguen usando, NO, yes, on y off se convierten en booleanos. Los números pierden los ceros finales y los ceros a la izquierda pueden leerse como octal. La solución es sencilla: pon entre comillas todo lo que deba seguir siendo texto.

country: "NO"
version: "1.10"
zip: "01234"

XML: documentos, esquemas y feeds empresariales

XML es más antiguo que los otros dos y trae funciones que ellos no tienen: espacios de nombres para mezclar vocabularios, esquemas (XSD) para validar la estructura con rigor, atributos y contenido mixto donde se intercalan texto y etiquetas. Eso lo hace ideal para documentos y para sistemas en los que importa un contrato formal: feeds RSS y Atom, servicios SOAP, estándares de facturación y banca, imágenes SVG, el pom.xml de Maven y los archivos que hay dentro de un DOCX o un XLSX.

Si empiezas algo nuevo y solo necesitas intercambiar datos, XML rara vez es la primera opción. Pero lo seguirás recibiendo de socios, sistemas heredados y fuentes de datos públicas, así que saber pasarlo a JSON es una habilidad muy práctica.

Comparación rápida

• Legibilidad: YAML > JSON > XML.
• Rigor y previsibilidad: JSON y XML no son ambiguos; YAML depende de la sangría y de la deducción de tipos.
• Comentarios: YAML y XML sí, JSON no.
• Validación: XML tiene las herramientas de esquemas más maduras; JSON Schema está muy extendido; YAML también suele validarse con JSON Schema.
• Hábitat típico: JSON para API y datos, YAML para configuración, XML para documentos e integración empresarial.

Convertir entre ellos: en qué fijarte

Como los tres describen árboles de datos, convertir suele ser sencillo. Aun así, conviene conocer algunos detalles:

• De YAML a JSON se pierden los comentarios. JSON no tiene dónde guardarlos. Las anclas y los alias (& y *) se expanden en copias normales.
• De JSON a YAML no se pierde nada. Todo JSON válido puede expresarse en YAML; en YAML 1.2, JSON es casi un subconjunto de YAML.
• Los atributos XML necesitan una convención. JSON no tiene atributos, así que los conversores los guardan como claves normales, a menudo con un prefijo como @. Revisa el resultado antes de pasárselo a otro programa.
• Un elemento frente a una lista. En XML, una <tag> y tres <tag> se escriben igual. Al pasar a JSON, una puede quedar como objeto y las otras como array, así que el código que use el resultado debe aceptar ambos casos.
• En XML todo es texto. 8080 y false son solo caracteres dentro de etiquetas; al pasar de XML a JSON puede que tengas que convertirlos de nuevo a número o booleano.
• De JSON a XML hace falta una única raíz y claves que sean nombres de elemento válidos (sin espacios y sin empezar por un dígito).

Convierte en tu navegador

Los conversores de datos de Azpy funcionan íntegramente en tu navegador: pega el texto o suelta un archivo y el resultado aparece al instante sin subir nada. Así puedes usarlos con tranquilidad con archivos de configuración que contienen nombres de servidores internos o respuestas de API con datos de clientes. Encontrarás JSON a YAML, YAML a JSON, XML a JSON y JSON a XML entre las herramientas.

Una regla rápida

Máquinas que hablan con máquinas → JSON. Personas que editan configuración → YAML, con comillas en todo lo ambiguo. Documentos, esquemas estrictos o un contrato empresarial existente → XML. Y cuando el formato que tienes no es el que necesitas, conviértelo y revisa los casos límite de arriba.