YAML a JSON — Cuándo convertir, cómo funciona y qué se pierde

Hace unos años ayudaba a un equipo a migrar su pipeline de CI/CD de una plataforma a otra. El sistema antiguo usaba JSON para sus definiciones de pipelines. El nuevo usaba YAML. No un gran problema en teoría — ambos formatos describen los mismos datos jerárquicos, ¿verdad?

En la práctica, pasé una cantidad vergonzosa de tiempo convirtiendo manualmente llaves en indentación, quitando comillas de las claves, y recordando que el null de JSON se convierte en ~ o null en YAML dependiendo del humor del parser. Trabajo tedioso y propenso a errores. Finalmente alguien me señaló una herramienta de conversión y me sentí genuinamente tonto por no haber usado una desde el principio.

Esta experiencia es común. YAML y JSON están en todas partes en el desarrollo moderno — configs de CI, Docker Compose, manifiestos de Kubernetes, respuestas de API, metadatos de paquetes — y se superponen lo suficiente como para que eventualmente necesites mover datos entre ellos.

Qué son realmente YAML y JSON

Ninguno de los dos es un lenguaje de programación. Son formatos de serialización de datos — formas de representar datos estructurados como texto para que diferentes sistemas puedan leerlos y escribirlos.

JSON (JavaScript Object Notation) fue diseñado a principios de los 2000 como alternativa ligera a XML para enviar datos entre clientes web y servidores. Estricto, mínimo y explícito: cada cadena entre comillas, cada objeto entre llaves, cada array entre corchetes, exactamente seis tipos de valor (cadena, número, objeto, array, booleano, null). Sin comentarios, sin cadenas multilínea sin escapar, sin forma de referenciar un valor definido anteriormente.

YAML (YAML Ain't Markup Language — sí, recursivo) llegó después y fue diseñado explícitamente para la legibilidad humana. Indentación para expresar anidamiento, cadenas sin comillas en la mayoría de los casos, comentarios con #, y anclas y alias para definir un valor una vez y referenciarlo en múltiples lugares. YAML 1.2 se define como un superconjunto de JSON.

En la práctica, JSON es el formato que se usa al comunicarse con APIs y necesitar comunicación confiable entre máquinas. YAML es el formato que se usa cuando los humanos escriben y mantienen la configuración — la indentación es más rápida de escanear que los corchetes, los comentarios son invaluables en los archivos de configuración.

Cuándo realmente necesitas convertir

Migración de plataforma CI/CD: Diferentes plataformas tienen diferentes preferencias. GitHub Actions usa YAML, algunas viejas configuraciones de Jenkins usan JSON. Migrar significa convertir las definiciones de pipelines.

Kubernetes y REST APIs: kubectl acepta YAML felizmente, la API de Kubernetes trabaja en JSON. ¿Escribir scripts directamente contra la API? JSON. ¿Escribir manifiestos para humanos? YAML.

Archivos de configuración y defaults de aplicaciones: Muchas aplicaciones envían configuraciones por defecto como JSON (porque son generadas por máquina) pero las documentan como YAML (porque los humanos leen los docs).

Depurar respuestas de API: Las APIs devuelven JSON. A veces quieres inspeccionar una respuesta, editarla y reproducirla — en YAML a veces es más fácil de leer.

Qué hace un convertidor YAML a JSON

La conversión tiene dos pasos: parsear el YAML en una estructura de datos en memoria, luego serializar esa estructura como JSON.

Las anclas y alias YAML se resuelven: YAML permite definir un valor con &anchor y referenciarlo con *alias. En JSON no hay equivalente — el valor referenciado simplemente se repite inline en todas partes donde se usa. El JSON resultante es correcto pero más verboso.

Ocurre inferencia de tipos: YAML hace tipado implícito. Un true desnudo se convierte en booleano, 42 en entero, 3.14 en float. JSON no conoce fechas y no distingue entre enteros y floats.

Los comentarios se eliminan: Esta es la pérdida más dolorosa. Los comentarios útiles que explican por qué un timeout está en 30 segundos o qué hace un flag críptico — desaparecidos después de la conversión. JSON no tiene sintaxis de comentarios.

La pesadilla de los booleanos YAML 1.1 vs 1.2

En YAML 1.1, los siguientes valores se tratan todos como booleanos:

true, false, yes, no, on, off
TRUE, FALSE, YES, NO, ON, OFF
True, False, Yes, No, On, Off

Eso significa que el inocente activado: yes se convierte en "activado": true. Y pais: NO — quizás un código de país ISO de Noruega — se convierte en "pais": false.

YAML 1.2 arregló esto en 2009 restringiendo los booleanos a solo true y false. Pero sorprendentemente muchos parsers YAML todavía implementan reglas 1.1.

La regla segura: en cualquier YAML que podría ser convertido, entrecomillar cualquier cadena que se parezca a un booleano. Escribir pais: "NO" y activado: "si" si se quieren cadenas. Este es el tipo de bug que tarda tres horas en rastrear y cinco segundos en arreglar.

¿Es seguro el roundtrip?

YAML a JSON a YAML: Se pierden comentarios, definiciones de anclas (se convierten en valores repetidos), y todas las opciones de formato del YAML original. El YAML resultante es correcto pero parece generado por máquina.

JSON a YAML a JSON: Para JSON estándar es en realidad bastante seguro. Como JSON es un subconjunto de YAML, el roundtrip preserva todos los datos.

Conclusión práctica: usar la conversión para tareas unidireccionales o en la misma dirección. Si necesitas mantener una configuración YAML y una representación JSON en paralelo, mantener una como fuente de verdad y generar la otra a partir de ella.

La herramienta YAML a JSON en ToolboxHubs

El convertidor YAML a JSON maneja todo lo descrito arriba:

1. Pegar el YAML — Acepta todo, desde simples configs clave-valor hasta manifiestos de Kubernetes profundamente anidados.
2. La salida JSON aparece instantáneamente — La conversión se ejecuta en el navegador, nada se envía a un servidor.
3. Copiar el resultado — Presionar el botón de copiar, listo.

La herramienta maneja anclas, cadenas multilínea, todos los tipos booleanos, valores null y estructuras anidadas. También valida el YAML mientras se escribe — si hay un error de indentación o un documento malformado, verás un mensaje de error en lugar de una salida silenciosamente incorrecta.

Para ir en la dirección contraria, el convertidor JSON a YAML está disponible. Mismo principio, dirección opuesta.

YAML vs JSON: la opinión directa

YAML cuando los humanos son los autores y lectores principales: Archivos de configuración, definiciones de pipelines CI, manifiestos de Kubernetes, playbooks de Ansible — estos viven en el control de versiones y son leídos, revisados y depurados por personas. La legibilidad de YAML y el soporte de comentarios importan de verdad.

JSON cuando las máquinas son los productores o consumidores principales: Respuestas de API, registros de base de datos, configuración generada, intercambio de datos entre servicios — estos no se benefician de la legibilidad porque nadie los escribe a mano. La rigurosidad y el soporte universal de JSON son lo que cuenta.

En la frontera — recibir JSON de una API pero configurar un sistema basado en YAML, o al revés — la conversión es solo una herramienta en el flujo de trabajo. Lo importante es entender qué puede cambiar en la conversión y verificarlo cuando algo sale mal.

Herramientas relacionadas

Validador YAML — Antes de convertir, verificar que el YAML es válido.

Formateador JSON — Después de convertir, el JSON puede salir en una línea larga. El formateador lo embellece con indentación configurable.

JSON a YAML — La dirección contraria. Mismo flujo de trabajo.

En conclusión

YAML y JSON son ambos buenos formatos de datos, pero para situaciones diferentes. Trabajar en su frontera — los humanos escriben YAML, los sistemas esperan JSON, o al revés — hace de la conversión una tarea rutinaria.

El convertidor YAML a JSON se encarga de la parte mecánica. Entender lo que se pierde en la conversión — comentarios, anclas, formato — ese fue el objetivo de este artículo.