YAML o JSON

JSON es un formato de datos estricto y mínimo que todos los lenguajes leen igual, por eso es la opción por defecto para las API y el intercambio de datos. YAML describe los mismos datos (objetos, listas, cadenas, números, booleanos, null) con sangría en lugar de llaves y admite comentarios, lo que lo hace más cómodo de escribir a mano en archivos de configuración. Todo documento JSON es también YAML 1.2 válido, pero YAML tiene más trampas: errores de sangría, valores convertidos en booleanos o fechas y cargadores inseguros.

Convertidor de YAML a JSON →

Los mismos datos en ambos formatos

Una pequeña configuración de servicio en JSON:

{
  "name": "web",
  "replicas": 2,
  "ports": [80, 443],
  "env": {"DEBUG": "false"}
}

Lo mismo en YAML:

# front web
name: web
replicas: 2
ports:
  - 80
  - 443
env:
  DEBUG: "false"

YAML quita llaves, corchetes, comas y la mayoría de las comillas, y añade un comentario. La estructura sale de la sangría con espacios; los tabuladores no se permiten para sangrar.

Lado a lado

	JSON	YAML
Comentarios	No	Sí (#)
Estructura	Llaves y corchetes	Sangría (solo espacios)
Comillas en cadenas	Siempre	Normalmente opcionales
Varios documentos por archivo	No	Sí (separados por ---)
Reutilizar un bloque	No	Anclas y alias (&nombre, *nombre)
Fechas	Sin tipo, cadenas	Algunos analizadores convierten 2026-11-10 en fecha
Uso típico	API, intercambio de datos, package.json	Kubernetes, Docker Compose, GitHub Actions, Ansible, OpenAPI

¿Cuáles son las trampas de YAML?

Booleanos implícitos. Con analizadores YAML 1.1, yes, no, on y off sin comillas se convierten en true o false. Ejemplo clásico: en una lista de códigos de país, NO (Noruega) pasa a ser false. Pon esos valores entre comillas: "NO".
Números que no lo son. Una versión 1.10 se convierte en el número 1.1, y un código postal como 01234 puede perder el cero o leerse en octal. Pon entre comillas todo lo que sea en realidad un identificador.
Sangría. Un espacio de más mueve una clave al padre equivocado sin ningún error. Usa un editor que muestre la sangría y valida el archivo.
Cargadores inseguros. Algunas bibliotecas YAML pueden construir objetos arbitrarios a partir de etiquetas, lo que ha provocado fallos de ejecución de código. Usa la función de carga segura (por ejemplo yaml.safe_load en Python); js-yaml 4 es seguro por defecto.

¿Cuál elegir?

De máquina a máquina (respuestas de API, colas de mensajes, registros): JSON, más simple de analizar, sin ambigüedad y leído de forma nativa por los navegadores.
Archivos que editan personas (configuraciones de despliegue, pipelines de CI): YAML, por los comentarios y la legibilidad, poniendo entre comillas los valores ambiguos y validando en CI.
La herramienta decide la mayoría de las veces: Kubernetes acepta ambos, GitHub Actions solo YAML y package.json solo JSON.

Convertir entre ambos no pierde datos; solo los comentarios, anclas y separadores de documentos de YAML no tienen equivalente en JSON. Para ver qué valores se volvieron cadenas, números o booleanos, convierte tu YAML a JSON y lee el resultado.

FAQ

¿El JSON es YAML válido?

Sí en YAML 1.2: un documento JSON puede leerlo un analizador YAML 1.2. Los analizadores YAML 1.1 antiguos también leen casi todo el JSON.

¿Se pueden poner comentarios en un archivo JSON?

No en JSON estándar. Algunas herramientas aceptan JSONC o JSON5, pero un analizador JSON estricto los rechazará.

¿Cómo convierto YAML a JSON?

Pega el YAML en el convertidor de YAML a JSON de este sitio; el convertidor de JSON a YAML hace lo contrario. Ambos funcionan en tu navegador.

Actualizado: noviembre de 2026. Los archivos se procesan en su navegador y no se envían a ningún servidor.

2026-11-12