Resultado de conversión de YAML a JSON en FormatArcResultado de conversión de YAML a JSON en FormatArc
Publicado: 2026-03-19Actualizado: 2026-05-15

YAML vs JSON en 2026: 7 diferencias clave y cuándo usar cada uno

YAML vs JSON en 2026: compara comentarios, tipos, anclas, velocidad, coste de tokens para LLM y errores comunes. Elige YAML para configuración y JSON para APIs.

YAML vs JSON: la respuesta corta

Si solo necesitas una línea: usa JSON para APIs e intercambio de datos entre máquinas, y usa YAML para archivos de configuración que editas a mano. Ambos describen el mismo modelo de datos (objetos, arreglos, cadenas, números y booleanos), pero JSON es estricto y verboso, mientras que YAML se basa en la indentación y admite comentarios.

JSON YAML
Sintaxis Llaves y corchetes Indentación
Comentarios No admitidos Admitidos (#)
Uso común APIs REST, intercambio de datos Archivos de configuración (Kubernetes, GitHub Actions)
Legibilidad Pensada para máquinas Pensada para personas
Rigor Estricto Permisivo

Puntos clave

  • JSON es estricto, rápido y pensado para máquinas; YAML se basa en la indentación, es más legible para personas y admite comentarios
  • JSON gana para APIs, flujos de logs y análisis de alto rendimiento; YAML gana para configuración editada a mano (Kubernetes, GitHub Actions, Ansible)
  • YAML admite comentarios, anclas, cadenas multilínea y fechas como tipos de primera clase; JSON no
  • Los prompts en YAML suelen ser entre un 10 y un 25 % más baratos en cantidad de tokens para un LLM, pero JSON se analiza más rápido y es más seguro con entradas no confiables

El resto de este artículo recorre las diferencias concretas, muestra los mismos datos en ambos formatos, compara casos de uso reales y explica los errores que conviene vigilar al convertir entre ellos. También abordamos una pregunta que se ha vuelto habitual en 2026: qué formato es más barato para alimentar el prompt de un LLM.

Ejemplos reales: dónde se usa cada formato

Antes de entrar en la sintaxis, este es el atajo que la mayoría de los ingenieros usa al decidir entre los dos:

  • Manifiestos de Kubernetes, charts de Helm: YAML
  • Archivos de Docker Compose: YAML
  • Pipelines de GitHub Actions, GitLab CI, CircleCI: YAML
  • Playbooks de Ansible: YAML
  • Cuerpos de solicitud y respuesta de APIs REST: JSON
  • package.json, composer.json, mensajes del navegador al servidor: JSON
  • Registros de logs y flujos de eventos: JSON Lines
  • Especificaciones OpenAPI / Swagger: YAML o JSON (los autores suelen elegir YAML, los generadores a menudo producen JSON)

Fíjate en el patrón. YAML gana cuando una persona va a leer o editar el archivo. JSON gana cuando un programa va a producirlo o consumirlo. Esa es la razón de fondo por la que los formatos evolucionaron como lo hicieron, y es la mejor regla práctica para elegir uno.

Lado a lado: los mismos datos en YAML y JSON

Aquí tienes una pequeña configuración de servidor web expresada en ambos formatos.

YAML:

# Web server configuration
server:
  host: localhost
  port: 8080
  debug: true
  allowed_origins:
    - https://example.com
    - https://staging.example.com
  headers:
    X-Frame-Options: DENY
    Strict-Transport-Security: "max-age=31536000"

JSON:

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true,
    "allowed_origins": [
      "https://example.com",
      "https://staging.example.com"
    ],
    "headers": {
      "X-Frame-Options": "DENY",
      "Strict-Transport-Security": "max-age=31536000"
    }
  }
}

Hay dos cosas que destacan. Primero, la versión en YAML es aproximadamente un 30 % más corta porque prescinde de la mayoría de las llaves, los corchetes y las comillas. Segundo, solo la versión en YAML puede llevar el comentario # Web server configuration; la versión en JSON lo pierde por completo.

Tipos de datos: lo que YAML admite y JSON no

Ambos formatos cubren cadenas, números, booleanos, null, objetos y arreglos. YAML añade algunos extras que facilitan la escritura de archivos de configuración.

Fechas y marcas de tiempo

Los analizadores de YAML aceptan fechas ISO 8601 como valores de primera clase:

release_date: 2026-04-01
created_at: 2026-04-01T09:30:00Z

JSON no tiene un tipo para fechas. Las fechas deben almacenarse como cadenas y ser analizadas por la aplicación que las recibe:

{
  "release_date": "2026-04-01",
  "created_at": "2026-04-01T09:30:00Z"
}

Cadenas multilínea

YAML tiene dos operadores para bloques de texto largos. El bloque literal (|) conserva los saltos de línea, mientras que el escalar plegado (>) los reemplaza por espacios.

description: |
  This service accepts webhooks from GitHub
  and forwards them to an internal queue.

summary: >
  All traffic is served through Cloudflare,
  and the origin is rate-limited to 100 rps.

JSON tiene que escapar los saltos de línea dentro de una sola línea:

{
  "description": "This service accepts webhooks from GitHub\nand forwards them to an internal queue.\n",
  "summary": "All traffic is served through Cloudflare, and the origin is rate-limited to 100 rps."
}

Inferencia de tipos flexible

YAML intenta inferir los tipos a partir de valores sin comillas. Según la versión de la especificación, yes, no, on y off pueden convertirse en booleanos. Los valores que parecen números se convierten en números. Esto resulta cómodo cuando las personas escriben los archivos, pero también es el origen del célebre "problema de Noruega": country: NO se analiza silenciosamente como false. JSON no tiene nada de esta ambigüedad: las cadenas siempre van entre comillas y los números siempre son números.

Comentarios: la ventaja de YAML para documentar

Los comentarios de YAML empiezan con # y se extienden hasta el final de la línea. Son muy valiosos para explicar por qué existe una configuración.

retries: 3  # Any higher and we exceed the upstream timeout

JSON no tiene sintaxis para comentarios. Las soluciones habituales (campos "_comment": "..." o las variantes no estándar JSONC y JSON5) existen precisamente porque la falta de comentarios hace que JSON sea incómodo para la configuración. Para la historia completa, consulta Cómo añadir comentarios a JSON.

Anclas y alias: la función de reutilización de YAML

YAML te permite definir un valor una vez con &anchor y referenciarlo en otro lugar con *alias. La clave de fusión <<: luego incorpora un bloque compartido dentro de un mapeo.

defaults: &defaults
  adapter: postgres
  host: db.internal
  pool: 5

development:
  <<: *defaults
  database: myapp_dev

production:
  <<: *defaults
  database: myapp_prod
  pool: 20

Cuando el archivo se convierte a JSON, el ancla se expande en línea: tanto development como production terminan con una copia completa de cada valor predeterminado. Los datos resultantes son correctos, pero la intención original de "estos comparten los mismos valores predeterminados" deja de ser visible.

Rendimiento, tamaño y velocidad de análisis

Para la comunicación entre máquinas, JSON es la opción más rápida. Los analizadores de JSON vienen incluidos en todos los entornos de ejecución de los lenguajes más usados (JSON.parse, json.loads, encoding/json) y están muy optimizados. El análisis de YAML es más lento porque la gramática es más rica, y de todos modos la mayoría de las bibliotecas de YAML construyen internamente un árbol equivalente a JSON.

Los archivos YAML suelen ocupar entre un 20 y un 30 % menos en disco, pero una vez que cualquiera de los dos formatos se comprime con gzip para el transporte, la diferencia de tamaño casi desaparece. El verdadero coste de YAML no son los bytes: es el tiempo de CPU del analizador y las sorpresas que provoca la inferencia implícita de tipos.

Cuándo elegir YAML

  • Una persona va a leer o editar el archivo a mano
  • El archivo es configuración, no una carga de datos
  • Necesitas comentarios para explicar las configuraciones
  • La cadena de herramientas ya espera YAML (Kubernetes, Docker Compose, Ansible, CI)
  • Quieres usar anclas y alias para reducir la duplicación

Si ya tienes JSON y quieres una forma más legible para personas, pégalo en JSON a YAML: el conversor conserva el anidamiento y te deja revisar la indentación en el navegador antes de guardar.

Cuándo NO usar YAML

Incluso cuando YAML parece la opción obvia, hay situaciones en las que causa más problemas de los que resuelve.

  • Configuración generada por máquinas: la inferencia de tipos convierte version: 2.0 en el número 2, corrompiendo los datos en silencio
  • Flujos de datos en tiempo real: la sobrecarga de análisis es significativa con alto rendimiento
  • Entradas sensibles a la seguridad: las etiquetas de YAML como !!python/object pueden ejecutar código arbitrario en cargadores inseguros; usa siempre yaml.safe_load o su equivalente
  • Cargas cortas y planas: el ahorro de la indentación desaparece y JSON es más sencillo

Cuándo elegir JSON

  • Un programa va a producir o consumir los datos
  • Necesitas interoperabilidad entre lenguajes sin sorpresas
  • Los datos se transmiten por la red en una API
  • Quieres un análisis estricto y sin ambigüedades, sin conversiones de tipo ocultas
  • El rendimiento importa: el análisis debe ser rápido y predecible

Cuando necesitas alimentar YAML escrito a mano a un programa que solo entiende JSON, YAML a JSON hace la conversión en el navegador con errores que indican el número de línea, lo cual es útil para detectar sorpresas de inferencia de tipos antes de que lleguen a producción.

Errores comunes al convertir YAML a JSON

La conversión es en su mayor parte sin pérdidas, pero un puñado de casos límite hace tropezar a la gente.

  • Los comentarios desaparecen: JSON no tiene sintaxis para comentarios, así que cada línea con # se descarta
  • Las anclas se expanden: los bloques compartidos se convierten en datos duplicados
  • Las fechas se vuelven cadenas: las fechas ISO pierden su información de tipo
  • Sorpresas de inferencia de tipos: un valor de YAML como version: 2.0 se convierte en el número 2 en JSON
  • Archivos con múltiples documentos: YAML puede contener varios documentos separados por ---; JSON debe elegir uno o envolverlos en un arreglo externo
  • Claves duplicadas: el comportamiento de YAML depende de la implementación; en JSON solo prevalece el último valor
  • Etiquetas y tipos personalizados: el !!timestamp de YAML o las etiquetas personalizadas no tienen una representación directa en JSON

Para el recorrido paso a paso, consulta Cómo convertir YAML a JSON. Una vez que tengas JSON, Consejos para formatear JSON cubre la indentación, el orden de las claves y otras decisiones que mantienen la salida fácil de revisar.

Convierte YAML ⇄ JSON con FormatArc

FormatArc ejecuta la conversión por completo en el navegador: sin subir nada, sin registrarse, nada sale de tu equipo.

Resultado de conversión de YAML a JSON con la entrada y la salida una al lado de la otraResultado de conversión de YAML a JSON con la entrada y la salida una al lado de la otra

  • YAML a JSON: pega YAML y obtén JSON, con mensajes de error que indican el número de línea cuando la sintaxis es incorrecta
  • JSON a YAML: la dirección inversa, produce YAML limpio con el anidamiento conservado
  • Formateador de JSON: formatea de forma legible el JSON resultante con informes de error claros

Si prefieres un flujo de trabajo con scripts, yq y yaml.safe_load de Python funcionan bien. Una línea rápida en Python:

python3 -c "import yaml,json,sys; print(json.dumps(yaml.safe_load(sys.stdin),indent=2))" < config.yaml

Preguntas frecuentes

¿Es YAML un superconjunto de JSON?

Desde YAML 1.2, todo JSON válido también es YAML válido. Un analizador de YAML puede leer un archivo JSON directamente. Lo contrario no es cierto: un analizador de JSON no puede leer YAML. En la práctica, muchas bibliotecas de YAML todavía usan por defecto la especificación más antigua YAML 1.1, donde esta compatibilidad es menos fiable.

¿Por qué Kubernetes y Docker Compose usan YAML en lugar de JSON?

Porque sus archivos de configuración los editan personas, y la sintaxis de YAML basada en indentación con comentarios es más fácil de mantener para configuraciones extensas. Cuando esas herramientas emiten estado (por ejemplo kubectl get ... -o json), normalmente ofrecen un modo JSON para el consumo por máquinas.

¿YAML se analiza más rápido que JSON?

No. JSON se analiza mucho más rápido en todos los lenguajes principales. YAML es más lento porque su gramática es más rica y ambigua. Para el transporte de datos sensible al rendimiento, JSON es la opción correcta.

¿Puedo convertir JSON a YAML sin perder datos?

Sí. La conversión de JSON a YAML casi siempre es sin pérdidas porque JSON es el formato más simple. No puedes añadir comentarios que JSON nunca tuvo, pero los datos en sí se transfieren de forma limpia. Pega tu entrada en el conversor de JSON a YAML para ver el resultado.

¿Por qué mi valor de YAML country: NO se convierte en false?

Este es el famoso "problema de Noruega". Los analizadores de YAML más antiguos interpretan el NO sin comillas como el booleano false. Se soluciona poniendo el valor entre comillas: country: "NO". La especificación YAML 1.2 eliminó este comportamiento, pero muchas herramientas todavía usan la 1.1 por defecto.

YAML vs JSON para prompts de LLM: ¿cuál usa menos tokens?

YAML suele ser más barato. Los tokenizadores como cl100k_base de OpenAI y el de Anthropic tratan las llaves, los corchetes y las comillas repetidas como tokens separados, así que el JSON profundamente anidado paga un impuesto estructural que YAML evita con la indentación. Para los mismos datos, los prompts en YAML suelen ser entre un 10 y un 25 % más cortos en cantidad de tokens. La contrapartida es que algunos modelos siguen una salida JSON estricta de forma más fiable que YAML. Un patrón común en 2026 es: alimentar YAML a la entrada y pedir JSON a la salida.

¿Sobreviven los comentarios de YAML a una ida y vuelta por JSON?

No. Los comentarios están vinculados a posiciones de línea en el archivo de origen, no a campos en la estructura de datos. Una vez que se analiza el YAML, los comentarios se descartan. Convertir YAML a JSON y de vuelta siempre los perderá; conserva el YAML original si necesitas mantener los comentarios.

Lecturas relacionadas

Resumen

  • YAML y JSON describen el mismo modelo de datos; la diferencia es quién lee el archivo
  • Elige YAML para configuración editada a mano con comentarios, elige JSON para el intercambio de datos entre máquinas
  • Vigila la inferencia de tipos, la expansión de anclas y la pérdida de comentarios al convertir YAML a JSON
  • FormatArc convierte en ambas direcciones en el navegador con informes de error que indican el número de línea