Caja de Herramientas

JSON frente a YAML: rigor sintáctico, comentarios y configuración

JSON y YAML expresan estructuras clave-valor y datos anidados, pero su carácter es opuesto: JSON es un contrato minucioso donde cada comilla y coma está regulada; YAML es una lista escrita al vuelo que transmite significado con la indentación y prescinde de comillas. El primero es la lengua franca del intercambio web; el segundo domina Kubernetes y el CI/CD.

DimensiónJSONYAML
Estilo de sintaxisEstricto: claves y cadenas entre comillas dobles según la especificación; llaves y corchetes definen la estructura sin ambigüedadRelajado: la indentación es jerarquía, las claves pueden ir sin comillas y las listas usan guiones; agradable para humanos pero sensible a espacios
ComentariosLa norma no los admite; para documentar hay que recurrir a campos extra o preprocesosComentarios # nativos, una razón clave de su dominio en configuración operativa duradera
Sistema de tiposSeis tipos fijos: objeto, arreglo, cadena, número, booleano, nulo; comportamiento idéntico en todos los lenguajesTipos más ricos: bloques multilínea, fechas, anclas y claves de fusión; pero conversiones implícitas como el «problema Noruega» (no se lee false) esconden trampas
Análisis y seguridadParsers rapidísimos integrados en los lenguajes (como JSON.parse) y superficie de ataque mínimaClaramente más lento; algunos cargadores antiguos permitían deserializar objetos arbitrarios provocando RCE: usa siempre carga en modo seguro
Frecuencia de erroresLos errores apuntan fila y columna exactas, fáciles de corregirLo habitual son fallos de indentación, mezcla de tabulaciones y tipos mal leídos, con errores señalando líneas equivocadas
Ecosistema de herramientasCobertura web total: navegadores, bases de datos (PostgreSQL/MongoDB) y sistemas de logs lo leen de serieEstándar de facto en DevOps: Kubernetes, GitHub Actions, Ansible y Docker Compose lo hablan todos
Ideal paraCuerpos de API, transporte front-back, datos generados por máquina o leídos entre programasConfiguración de infraestructura escrita a mano, manifiestos de despliegue y definiciones de pipelines

¿Cuándo elegir JSON?

Cuando los datos fluyen entre programas —APIs, colas de mensajes, serialización— elige JSON. No admite ambigüedad, analiza más rápido, tiene bibliotecas en todas partes y la automatización no teme que el editor estropee la indentación.

¿Cuándo elegir YAML?

Cuando los archivos los escriben, editan y leen personas —manifiestos de K8s, pipelines de CI, archivos Compose— elige YAML. Los comentarios y la sintaxis limpia reducen el coste de colaboración, y la validación por esquema caza la mayoría de erratas.

Herramientas relacionadas

Preguntas frecuentes

¿De verdad JSON no admite comentarios?

La norma efectivamente lo prohíbe. Su creador eliminó los comentarios para mantener el análisis consistente entre implementaciones. Salidas: campos «_comment», extensiones JSON5/JSONC o documentación externa.

¿Cuál es el «problema Noruega» de YAML?

Un no sin comillas se interpreta como el booleano false y no como el código de país; on/off/yes igual. Basta poner comillas a toda cadena ambigua.

¿Puedo convertir JSON existente directamente a YAML?

Sí: ambos expresan estructuras anidadas de forma equivalente y la conversión no pierde datos. Tras convertir, revisa claves que empiezan por números y valores especiales que quizá requieran comillas.

Para saber más

En la práctica conviven constantemente: GitHub Actions define flujos en YAML mientras procesa cargas JSON dentro de ellos; las plantillas de Helm se escriben en YAML pero llegan como JSON al servidor API. Dominar la conversión rinde más que discutir cuál es mejor: nuestros conversores JSON/YAML cambian de formato en un clic con validación de sintaxis, todo local. Regla práctica: JSON para máquinas, YAML para personas.

← Volver a las comparaciones