Formateador y validador de YAML

Pega YAML para formatearlo y validarlo. Visualiza los errores al instante, corrige la indentación y convierte a JSON.

Procesado localmente · no se envía nada a un servidor
Pega YAML para validar

¿Qué es YAML?

YAML (YAML Ain't Markup Language) es un formato de serialización de datos legible por humanos, utilizado para archivos de configuración (Docker, Kubernetes, GitHub Actions, Ansible), intercambio de datos y más. Utiliza indentación en lugar de llaves y es un superconjunto de JSON.

Preguntas frecuentes

¿Qué errores detecta el validador?

Errores de indentación, dos puntos faltantes, claves duplicadas, caracteres no válidos, cadenas sin cerrar, anidamientos incorrectos y otros problemas de sintaxis YAML. Los mensajes de error incluyen los números de línea.

¿Puedo convertir el YAML a JSON?

¡Sí! Haz clic en el botón «→ JSON» para convertir tu YAML a JSON bien formateado. Para la conversión inversa, usa nuestro Convertidor JSON a YAML.

Un recorrido rápido por YAML

YAML 1.0 fue publicado en 2001 por Clark Evans, Ingy döt Net y Oren Ben-Kiki; YAML 1.1 le siguió en 2005, y la versión actual es YAML 1.2.2, que corrigió varios problemas históricos (en especial el «problema de Noruega», véase más abajo) y se diseñó para ser un superconjunto estricto de JSON. La especificación oficial está en yaml.org/spec/1.2.2. Este formateador usa la biblioteca de código abierto js-yaml, que analiza con el esquema YAML 1.2 de forma predeterminada, así que la mayoría de las peculiaridades heredadas de la versión 1.1 no se aplican al texto formateado aquí, pero sí se aplican a la mayoría de las herramientas YAML del lado del servidor a las que enviarás la salida.

Dónde vive YAML en realidad

YAML se ha impuesto como el formato de configuración de la infraestructura nativa de la nube. Los lugares donde más te lo encontrarás:

La trampa de los espacios en blanco (solo espacios)

YAML usa la indentación para denotar la estructura, y la especificación es explícita en que no se permiten tabuladores para la indentación. Solo espacios. Esta es la fuente de errores más común en el YAML escrito a mano, sobre todo porque muchos editores mezclan tabuladores y espacios de forma silenciosa según su configuración. El mensaje de error que te dará un analizador estricto es algo parecido a «found character '\t' that cannot start any token»; traducción: «usaste un tabulador en algún sitio». La solución es universal: activa «mostrar espacios en blanco» en tu editor y convierte cada tabulador en dos o cuatro espacios.

El tamaño de la indentación es una convención, no parte de la especificación. 2 espacios es el estándar de facto para los manifiestos de Kubernetes, GitHub Actions y la mayor parte del YAML que leerás en la web moderna. 4 espacios es más habitual en Ansible. La regla que importa: sé coherente dentro de un mismo archivo. Mezclar 2 y 4 espacios entre claves hermanas es lo que hace tropezar a los analizadores, no el tamaño que elijas.

El problema de Noruega (y por qué deberías entrecomillar las cadenas ambiguas)

YAML 1.1 (todavía el predeterminado en PyYAML, snakeyaml y muchos otros analizadores del lado del servidor) interpreta una larga lista de grafías booleanas sin comillas como booleanos reales: true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off. La trampa famosa: el código de país ISO de Noruega es NO. Una configuración YAML que enumera países como cadenas sin comillas analiza Noruega en silencio como el booleano false, y el código posterior que lee countries[0] == 'NO' falla de forma desconcertante.

YAML 1.2 (y el esquema predeterminado de js-yaml) restringió los booleanos a solo true / false, lo que corrige el problema de Noruega a nivel del analizador. Pero muchas herramientas del mundo real todavía usan el esquema YAML 1.1 de forma predeterminada por retrocompatibilidad. El hábito defensivo: entrecomilla cualquier cadena que parezca que podría ser un booleano, un número, una fecha o una versión. country: "NO", postal_code: "01234", version: "1.10", time: "10:30". Las comillas son el desambiguador universal.

Otras trampas de coerción de tipos

Estilo de bloque frente a estilo de flujo

YAML admite dos notaciones para los mismos datos:

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

El estilo de bloque es lo que verás en el 99 % del YAML escrito a mano: es lo que hace que el formato sea legible. El estilo de flujo es una vía de escape útil para valores cortos de una sola línea o para generar YAML mediante programación, cuando prefieres no llevar el control de la indentación. El formateador normaliza la salida a estilo de bloque (la forma más legible), con independencia del estilo que haya usado tu entrada.

Anclas y alias (el truco DRY)

La función de reutilización de YAML: define un valor una vez con el ancla &name y haz referencia a él en otro lugar con el alias *name. Cómodo para archivos de configuración largos donde el mismo bloque de valores aparece varias veces.

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

Algunas advertencias: no todos los procesadores de YAML admiten las anclas y los alias (en especial algunas herramientas de manifiestos de Kubernetes más antiguas y ciertos contextos de Helm). La sintaxis de «clave de fusión» <<: que se muestra arriba es una extensión de YAML 1.1 y está oficialmente obsoleta en la 1.2; js-yaml la admite, pero los analizadores de 1.2 puros puede que no.

Archivos multidocumento

Un solo archivo YAML puede contener varios documentos, separados por ---. Es habitual en Kubernetes: un archivo con un Deployment, un Service y un ConfigMap, separados por ---, aplicados con un solo kubectl apply -f:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML frente a JSON frente a TOML

Si puedes elegir para una configuración nueva: TOML para la configuración plana, YAML si necesitas un anidamiento profundo y el ecosistema se ha estandarizado en él (Kubernetes, Ansible), JSON si lo escribe una máquina. YAML es el formato adecuado cuando las personas necesitan leer una configuración profundamente anidada y escribir comentarios significativos en línea.

Privacidad

Las configuraciones de YAML contienen con frecuencia secretos que no deberían pasar por el servidor de otra persona: los blobs en base64 de los Secret de Kubernetes, las contraseñas de bases de datos en application.yml, las claves de API en los flujos de trabajo de CI, los nombres de host internos en las configuraciones de despliegue. El formateador se ejecuta enteramente en tu navegador mediante la biblioteca de código abierto js-yaml: el contenido pegado se analiza y se vuelve a emitir localmente, sin ninguna petición de red, sin subidas y sin registros. Cerrar la pestaña lo borra todo.

Errores frecuentes

  1. Mezclar tabuladores y espacios en la indentación. El error más común. Los tabuladores están prohibidos por la especificación; algunos editores los insertan de forma silenciosa. Muestra los espacios en blanco en tu editor.
  2. Indentación incoherente entre elementos hermanos. Las claves hermanas deben estar alineadas en la misma columna. La indentación mixta de 2/4 espacios rompe el análisis.
  3. Valores sin comillas que parecen booleanos, números, fechas u horas. NO, 012, 1.10, 10:30, yes: entrecomíllalos.
  4. Falta el espacio después de los dos puntos. key: value funciona; key:value no es válido (se analiza como una sola cadena).
  5. Espacios en blanco al final. Algunos analizadores tratan los espacios finales como significativos; otros no. El hábito seguro entre herramientas es eliminar los espacios en blanco al final.
  6. Cadenas multilínea sin el escalar de bloque adecuado. Las cadenas largas necesitan | (literal, conserva los saltos de línea) o > (plegado, une las líneas). El texto multilínea plano y sin comillas rara vez se comporta como esperas.
  7. Suponer que las anclas y los alias están en todas partes. Helm y algunos contextos de Kubernetes no admiten del todo &/*. Pruébalos en tu pipeline real antes de depender de ellos.
  8. Discordancias de codificación. Los archivos YAML deberían estar en UTF-8. Un editor de Windows que guarda como UTF-16 con BOM produce archivos que algunos analizadores no pueden leer.

Más preguntas frecuentes

¿El formateador conservará mis comentarios?

No. La biblioteca js-yaml analiza el YAML para obtener un valor de JavaScript y lo vuelve a emitir a partir de ese valor, lo que significa que los comentarios (# like this) se descartan: viven en el texto de origen, no en la estructura analizada. Si conservar los comentarios importa (y suele importar en los archivos de configuración cuidados a mano), usa una alternativa que conserve los comentarios, como eemeli/yaml mediante su API de CST, o haz pequeñas ediciones a mano en lugar de pasar por este formateador en ida y vuelta.

¿Por qué el analizador de YAML de mi servidor trata mi NO como un booleano?

Porque ese analizador usa YAML 1.1 (el predeterminado en PyYAML, snakeyaml y muchos otros), que interpreta NO como el booleano false. Este formateador usa YAML 1.2 de forma predeterminada (mediante js-yaml), así que no desencadena el error aquí, pero en cuanto envías el archivo a un entorno YAML 1.1, la trampa se activa. Entrecomilla siempre las cadenas ambiguas: country: "NO".

¿Puedo convertir YAML a JSON?

Sí, haz clic en «→ JSON». La conversión es sin pérdidas para todo lo que se puede representar en JSON (cadenas, números, booleanos, null, arrays, objetos). Lo que no sobrevive: los comentarios (JSON no tiene sintaxis para ellos), las anclas y los alias (JSON no tiene equivalente) y los tipos de fecha y marca de tiempo de YAML (que se convierten en cadenas en JSON). Para la dirección inversa, usa la herramienta dedicada de JSON a YAML.

¿Se envía algo a un servidor?

No. Todo el análisis, el formateo y la conversión a JSON se ejecutan en tu navegador mediante js-yaml. El YAML pegado nunca se transmite a ningún servidor. Esto importa porque las configuraciones de YAML contienen con frecuencia secretos (valores de los Secret de Kubernetes, contraseñas de bases de datos, claves de API, puntos de conexión internos) que no deberían subirse a un servicio de terceros.

¿Cuál es el límite de tamaño?

No hay un límite estricto: el formateador se ejecuta en la memoria de tu navegador. Los manifiestos típicos de Kubernetes (unos pocos KB) y los charts de Helm (decenas de KB) se formatean al instante. Los archivos multidocumento muy grandes (varios MB) pueden ir lentos, pero por lo general funcionan; si tienes un chart de Helm de 10 MB, formatéalo localmente con una herramienta de línea de comandos.

¿Por qué YAML es tan propenso a errores?

Tres razones que se acumulan: (1) los espacios en blanco significativos hacen que las erratas provoquen cambios semánticos silenciosos; (2) la coerción de tipos permisiva de YAML 1.1 convierte cadenas ambiguas en booleanos o números no deseados; (3) el formato tiene demasiadas formas de escribir lo mismo (bloque frente a flujo, comillas simples frente a dobles, tres variantes de cadenas multilínea). Los hábitos defensivos (entrecomillar siempre, ser coherente con la indentación, validar antes de desplegar) corrigen la mayor parte de la superficie expuesta.

Herramientas relacionadas

Convertidor JSON → YAML

Convierte entre los formatos JSON y YAML.

Formateador JSON

Formatea, valida y embellece datos JSON.

Formateador XML

Formatea, embellece o minifica XML.