Saltar al contenido principal
ToolsByUs

JSON vs YAML

JSON es el formato de intercambio: estricto, sin comentarios y entendido por todas las APIs y parsers. YAML es el formato de configuración humana: con ámbito por indentación, amable con los comentarios y tecleable a mano. Elige JSON para programas que hablan con programas y YAML para personas que escriben a programas — y convierte sin pérdidas en ambas direcciones.

Solo local

JSON vs YAML: explicación

Los dos formatos se presentan a menudo como rivales, lo que oculta la verdad útil: resuelven problemas distintos, y la mayoría de los proyectos reales usan ambos. JSON ganó el intercambio de datos porque su gramática cabe en una tarjeta y porque una carga que un servicio emite, otro la puede consumir sin configuración compartida. YAML ganó la configuración porque quienes lo editan son humanos frente a un editor de texto, y los humanos quieren comentarios, listas legibles y la libertad de saltarse las comillas.

El precio de esa amabilidad humana es una especificación que los propios autores de YAML describen como complicada: la indentación lleva significado, el tipo de un escalar desnudo se infiere (y el fallo clásico es un valor como `no` convirtiéndose en silencio en el booleano false), y un archivo puede procesarse diciendo algo que su autor nunca quiso decir. La rigidez de JSON es justo lo que lo hace aburrido —un número es un número, una cadena es una cadena, y ningún editor puede reformatear tu archivo en un documento distinto—.

La comparación de abajo se queda en el nivel donde las contrapartidas realmente muerden: reglas de sintaxis, comportamiento del tipado, comentarios, tamaño y las herramientas que cada formato presupone. Cuando necesites cruzar de uno a otro, ambas direcciones tienen convertidores honestos en este sitio —y como todo aquí, se ejecutan por completo en tu navegador—.

Pasar la configuración a tabla para revisarla en una hoja de cálculo es un paso habitual, y el el convertidor de YAML a CSV lo hace sin salir de la pestaña.

¿Necesitas la conversión exacta que compara esta página? El el convertidor de YAML a JSON ejecuta el ciclo de procesar y emitir en tu navegador, sin subir nada.

Sintaxis: puntuación frente a indentación

La gramática de JSON usa seis caracteres estructurales —corchetes, llaves, dos puntos y coma—, así que el anidamiento de un documento se ve en su puntuación y un linter puede señalar el carácter exacto que está mal. YAML gasta su presupuesto de puntuación en legibilidad: el anidamiento es indentación, las listas son guiones y los pares clave/valor no necesitan separador más allá de dos puntos y un espacio. El resultado es que un documento JSON de cinco líneas se vuelve dos líneas de YAML, y uno profundamente anidado se acorta dramáticamente —al precio de una clase de error entera que JSON no tiene: el fallo del número incorrecto de espacios, que algunos parsers reportan en una línea que no pinta nada cerca de tu equivocación—.

AspectoJSONYAML
Marcador de ámbitoLlaves y corchetesIndentación (solo espacios)
ComentariosNinguno — eliminados por diseño# hasta fin de línea
EntrecomilladoObligatorio en cada cadenaOpcional para la mayoría de los escalares
Cadenas multilíneaSolo escapes \nEscalares en bloque (| y >)
Anclas / reutilizaciónNingunaAnclas & y alias *
Tamaño de la gramáticaCabe en una página (RFC 8259)Multietapa, famosamente compleja

Tipos: estrictos frente a inferidos

Cada valor JSON se declara a sí mismo: las cadenas llevan comillas, los números van desnudos, los booleanos son exactamente true y false. YAML infiere. Un yes, no, on, off, true o false desnudo es un booleano; un 2026-09-19 desnudo es una fecha; y un valor como 1.20 puede convertirse en silencio en el número 1.2 según el lector. El fallo tiene nombre en la comunidad —el problema de Noruega, por códigos de país como NO que se vuelven el booleano false—, y es el argumento más fuerte para entrecomillar a la defensiva en YAML incluso cuando el parser no lo exige.

La otra cara es deliberada: YAML quiere archivos de configuración donde 8080 se lea como número de puerto sin ceremonia. JSON quiere intercambio, donde el emisor y el consumidor deben estar de acuerdo en cada byte, y la inferencia es un bug. Cada formato optimiza para el lector que espera.

Tamaño, rendimiento y herramientas

YAML suele ser el archivo más corto y el procesado más lento: escanear indentación, escalar los bloques multilínea y resolver anclas cuestan más que la gramática de JSON de una sola pasada. Para configuración que se lee una vez al arrancar esto es irrelevante; para un formato de transmisión que fluye millones de veces al día es exactamente por qué YAML nunca desplazó a JSON en la transmisión. Las herramientas son la otra asimetría —todos los lenguajes traen un parser de JSON en su biblioteca estándar, mientras que los parsers de YAML son de terceros con diferencias reales en lo que aceptan, que es por lo que este convertidor documenta el subconjunto que soporta en lugar de prometer la especificación completa—.

  • Tamaño de carga: YAML gana en archivos escritos a mano; JSON con minificación suele ganar en la transmisión, porque sus reglas de entrecomillado comprimen de forma predecible.
  • Mensajes de error: los parsers de JSON señalan el carácter culpable; los parsers de YAML señalan la línea donde la indentación dejó de coincidir.
  • Interoperabilidad: JSON es el valor por defecto en todas partes —flujos de logs, APIs HTTP, almacenamiento del navegador—. YAML es el predeterminado en Kubernetes, flujos de CI y Ansible.
  • Viajes de ida y vuelta: JSON→YAML→JSON es sin pérdidas con un par que cumpla la especificación. YAML→JSON puede tener pérdidas en cuanto el archivo usó características que JSON no tiene —anclas, varios documentos o claves que no son cadenas—.

Cuándo elegir cuál

La decisión rara vez va de preferencias y suele ir del lector. Elige JSON cuando un programa produce el documento y otro programa lo consume: cargas de API, logs estructurados, estado almacenado, cualquier cosa que cruce un límite de confianza. Elige YAML cuando una persona escribe y mantiene el documento: flujos de CI, manifiestos de Kubernetes, archivos docker-compose, cualquier configuración donde quien revisa necesita leer un diff y entenderlo sin descifrar puntuación.

Y la recomendación se invierte con claridad: si te sorprendes dando formato a mano a un JSON con quince niveles de anidamiento, ese archivo probablemente quiere ser YAML. Si te encuentras procesando YAML en tiempo de ejecución dentro de un servicio, ese archivo probablemente quiere ser JSON. Los convertidores enlazados abajo hacen del cruce un paso de un clic en lugar de un proyecto de migración.

Preguntas frecuentes

¿YAML es un superconjunto de JSON?

YAML 1.2 hizo explícitamente que la mayoría de los documentos JSON fueran YAML válido —un archivo JSON con sus llaves intactas normalmente se procesa como YAML sin cambios—. Al revés nunca es cierto: comentarios, anclas, claves desnudas y cadenas multilínea no tienen representación JSON. Así que la ruta de migración es unidireccional por diseño, y las herramientas que presumen de fidelidad total YAML→JSON están eligiendo en silencio un subconjunto.

¿Qué formato se procesa más rápido?

JSON, por un margen amplio y constante. Su gramática es de una sola pasada y sin estado de indentación; los escáneres de YAML siguen el contexto de columna, resuelven escalares en bloque y expanden anclas. Para configuración de arranque la diferencia son milisegundos e irrelevante; para tráfico de máquina a máquina de gran volumen es una de las dos razones por las que JSON domina la transmisión (la otra, el soporte universal en las bibliotecas estándar).

¿Por qué los sistemas de CI y Kubernetes usan YAML en lugar de JSON?

Porque sus documentos los escriben y revisan humanos. Los comentarios de YAML dejan que un manifiesto se explique en línea, la indentación mantiene legibles las especificaciones profundas de recursos y los diffs muestran la intención con claridad. Las mismas propiedades que hacen a YAML arriesgado para el intercambio —la inferencia, la sensibilidad a la indentación— son fortalezas para configuración mantenida a mano.

¿Qué es el problema de Noruega en YAML?

Varios parsers de YAML tipan los escalares desnudos por inferencia, así que un código de país como NO (Noruega) se procesa como el booleano false, y off u on se vuelven booleanos también. El arreglo es entrecomillar cualquier valor que deba seguir siendo una cadena. JSON es inmune por construcción —sin comillas significa número o booleano, con comillas significa cadena, sin ningún paso de inferencia que errar—.

¿Puede perder datos convertir YAML a JSON?

Puede, en tres casos documentados: varios documentos en un archivo (solo el último sobrevive a un convertidor de documento único), anclas y alias (deben expandirse, lo que duplica contenido) y claves que no son cadenas. Los convertidores de este sitio rechazan o reportan claramente esos casos en lugar de remodelar el documento en silencio.

¿Debo indentar YAML con 2 o 4 espacios?

Ambos son válidos —YAML prohíbe los tabuladores, no una cantidad de espacios—, pero 2 espacios es la convención abrumadora en los ecosistemas de Kubernetes, CI y Docker, y mezclar anchos dentro de un archivo es así como nacen los errores de indentación. Elige 2, haz que tu editor lo imponga, y cada diff seguirá siendo legible.

¿Dónde puedo leer las normas citadas aquí?

  • RFC 8259 — El formato de intercambio de datos JavaScript Object Notation (JSON)
  • YAML 1.2 — Especificación de YAML, versión 1.2 (revisión 1.2.2)
Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas