Pega dos documentos YAML y obtén un diff preciso lado a lado. Pensado para manifiestos de Kubernetes, workflows de GitHub Actions, valores de Helm y archivos docker-compose.
Una herramienta gratuita en el navegador para comparar dos documentos YAML. Pega la versión antigua a la izquierda, la nueva a la derecha, y las diferencias se resaltan carácter a carácter. El texto no sale de tu navegador, lo que importa cuando estás haciendo diff de manifiestos con referencias a secretos u hostnames internos.
El diff es a nivel de carácter, el mismo motor que usa nuestra herramienta de diff de texto. El modo YAML del editor hace el resaltado de sintaxis según la especificación YAML 1.2.2, así que tus block scalars, anchors y flow collections aparecen con los colores correctos.
Si alguna vez te has quedado mirando un diff de 400 líneas de un values.yaml de Helm en un pull request buscando el desliz de indentación que rompió el chart, esta es la herramienta que lo encuentra en segundos. También sirve cuando copiar y pegar entre Slack y tu editor convierte espacios en tabs, que YAML rechaza sin contemplaciones.
El diff trabaja a nivel de carácter y luego una pasada de limpieza semántica agrupa los resaltados en bloques con sentido en lugar de caracteres sueltos dispersos. Las inserciones aparecen en verde en el panel derecho, las eliminaciones en rojo en el izquierdo, y los contadores de cada cabecera te dicen cuántas ediciones distintas detectó el diff.
YAML tiene reglas de parseo que muerden a quien lo trata como un formato indulgente. La indentación es estructural según la spec de YAML 1.2.2, así que un solo espacio mal puesto cambia el árbol del documento. Los tabs están prohibidos como indentación, y el parser los rechaza sin más. El typing implícito convierte el token sin comillas NO en el booleano false en YAML 1.1, lo que es el famoso Norway problem: las listas de códigos de país pierden a Noruega sin avisar. YAML 1.2 acotó las reglas para que solo true, false, null y formas numéricas se conviertan sin comillas, pero un montón de herramientas siguen parseando 1.1.
Si ya has convertido tu YAML a JSON para un consumidor aguas abajo, nuestra herramienta de diff de JSON se ocupa de cuestiones estructurales como el orden de claves y la canonicalización. JSON es un subconjunto estricto de YAML 1.2, así que cualquier documento JSON válido es también YAML válido: esa compatibilidad está documentada en la spec y es la razón por la que js-yaml y libyaml hacen round-trip de JSON sin sorpresas.
Dos paneles de texto, un diff. Sin registro, sin subida, sin viaje al servidor.
Pega el YAML antiguo a la izquierda, el nuevo a la derecha. O pulsa Subir en cualquiera de los lados para cargar directamente un archivo .yaml o .yml. El botón Ejemplo rellena ambos paneles con un Deployment de Kubernetes pequeño para que veas la herramienta en acción primero.
YAML usa solo espacios para la indentación, nunca tabs. Si pegaste desde un cliente de chat o una terminal que convirtió los espacios en tabs, el parser rechazará el archivo. El editor resalta los tabs y los espacios al final de línea para que los detectes antes de que provoquen un fallo en el deploy.
Las eliminaciones aparecen en rojo a la izquierda, las inserciones en verde a la derecha. Ambos paneles se desplazan a la vez para que sigas manifiestos largos sin perderte. Los contadores de cambios en cada cabecera resumen cuántas ediciones distintas encontró el diff.
Ejecuta kubectl get deployment web -o yaml en ambos clusters y haz diff de la salida. A menudo prod sigue con replicas: 2 y un tag de imagen viejo porque un rollout de fin de sprint nunca llegó allí, y un diff de texto es la forma más rápida de confirmarlo antes de volver a lanzar kubectl apply. El modelo de objetos de Kubernetes es YAML de cabo a rabo, así que este es el caso del día a día.
Cuando un workflow deja de dispararse tras renombrar una rama o un job tarda de pronto 8 minutos más, haz diff de .github/workflows/ci.yml contra el último commit en verde. El culpable suele ser un filtro on: cambiado, una clave cache: eliminada en actions/setup-node, o una entrada de la matriz que pasó silenciosamente de node-version: "18" (string) a node-version: 18 (número) y rompió el type checker.
Haz diff de docker-compose.yml contra la versión en main para verificar qué entradas de environment: cambiaste de verdad. La gente pega una lista de variables nuevas y olvida que una de ellas ya estaba puesta en otro servicio, y el override cambia un flag en otro sitio sin avisar. El diff lo deja a la vista.
Al subir un chart de 1.8.0 a 2.0.0, haz diff de tu values.yaml contra los nuevos defaults que publicó el mantenedor. Helm fusiona los valores clave a clave, así que una clave de nivel superior renombrada (image.tag moviéndose bajo image.repository) cae silenciosamente al default del chart. El diff destapa el rename antes de que helm upgrade despliegue una regresión.
Un diff de un openapi.yaml de 3.000 líneas es ilegible cuando un generador de código reordena paths alfabéticamente. Compara las versiones lado a lado y aparece el cambio real: un campo required añadido a un esquema de petición, o una respuesta cuyo tipo cambió silenciosamente de string a integer. Más fácil que escarbar en un SDK generado para encontrar por qué se rompió la build.
Cuando un playbook funciona en dev y falla en prod, haz diff del inventory o del defaults/main.yml del role entre ambos. Una causa habitual es un hostvar que nunca se copió, o un become: yes que estaba en el role en dev y en una sola task en prod. El diff lo encuentra en segundos.
Una hoja resumen para los casos límite de parseo que esta herramienta destapa más a menudo. Todo basado en la especificación YAML y en el comportamiento real de los parsers.
| Topic | What this tool does |
|---|---|
| Indentación | Solo espacios, y la cuenta es estructural. Dos y cuatro espacios son habituales; elige uno por archivo y mantenlo. La página de YAML en Wikipedia tiene un buen resumen si te interesa la historia. |
| Tabs | Prohibidos como indentación según la spec. Permitidos dentro de valores escalares. Si tu editor inserta un tab al pulsar Enter, configúralo para que use espacios en archivos .yaml y .yml. |
| Anchors y aliases | &name define un anchor; *name lo referencia. Útil para repetir bloques grandes como las env vars de un contenedor o la configuración por defecto de un servicio sin copiar y pegar. |
| Merge keys | <<: *base fusiona el mapping referenciado en el actual. Es una característica de YAML 1.1. La mayoría de parsers, incluido libyaml, la siguen aceptando; la spec de YAML 1.2 la quitó. |
| Archivos multi-document | Tres guiones (---) separan documentos en un mismo stream. Útil para meter varios objetos de Kubernetes por un único kubectl apply -f. ... termina un documento. |
| Block scalars | | conserva los saltos de línea (literal); > los pliega como espacios. Los modificadores - y + controlan los saltos finales. Usa | para scripts de shell y > para prosa larga. |
| El Norway problem | Sin comillas, NO, YES, ON, OFF se convierten en booleanos en YAML 1.1. Entrecomíllalos o usa un parser 1.2. Mira las definiciones de tipos de YAML para saber qué strings se convierten. |
| Codificación | La spec de YAML 1.2 exige UTF-8. UTF-16 está permitido con BOM. En la práctica las herramientas esperan UTF-8 sin BOM, así que guarda los archivos así para evitar sorpresas. |
YAML es sensible al whitespace, así que un diff de texto normal ya es útil: cualquier cambio de indentación es un cambio estructural, y el diff lo pilla. La diferencia está en la presentación. El modo YAML colorea anchors, tags, block scalars y flow collections con los colores de sintaxis, así que de un vistazo sabes si el cambio es a una clave, a un valor de tipo string o a un elemento de lista. El algoritmo de diff por debajo es el mismo que el de nuestra herramienta de diff de texto.
Porque la indentación es lo único que le dice al parser qué claves pertenecen a qué mapping. La spec de YAML 1.2.2 define el nivel de indentación de un nodo por la cantidad de espacios al principio, y prohíbe los tabs como indentación. Un solo espacio extra promueve una clave a un sub-mapping. Esa rigidez es el precio de un formato que no necesita llaves ni comas, y es la razón por la que ves más bugs de indentación en YAML que en JSON.
El typing implícito de YAML 1.1 convierte el token sin comillas NO en el booleano false. Así que una lista de códigos de país que incluya NO para Noruega se convierte silenciosamente en una lista con una entrada reemplazada por false. Pasa lo mismo con YES, ON, OFF y similares. StrictYAML lo documenta en detalle. La solución es entrecomillar el valor ("NO") o usar un parser que siga YAML 1.2, que solo convierte true, false y null de forma implícita.
Un anchor (&name) marca un nodo para que puedas referenciarlo después con un alias (*name), evitando repeticiones en archivos largos. La merge key (<<: *name) era una extensión de YAML 1.1 que copia todas las claves del mapping referenciado al actual, útil para compartir configuración común entre servicios. Las merge keys no forman parte de YAML 1.2, pero la mayoría de parsers, incluido js-yaml, las siguen aceptando por compatibilidad. El diff trata los anchors y aliases como texto plano, así que un anchor renombrado se ve con claridad.
Sí. JSON es un subconjunto estricto de YAML 1.2, así que cualquier documento JSON válido es también un documento YAML válido. Puedes mezclar los dos si quieres, dejando una flow collection estilo JSON dentro de un archivo en estilo bloque. Para trabajar con JSON puro, nuestra herramienta de diff de JSON tiene botones de formatear y validar específicos para JSON, incluido pretty-print y ordenar claves.
Porque la spec de YAML prohíbe los tabs como indentación. De la spec 1.2.2: "To maintain portability, tab characters must not be used in indentation". Los tabs sí están permitidos dentro de valores escalares (un string puede contener un tab), solo no al principio de la línea, donde se mide la indentación. La solución es un buscar y reemplazar rápido de tab a dos o cuatro espacios, según la convención que ya use tu archivo.
Tu YAML no sale de tu navegador. El editor, el resaltador de sintaxis y el diff se ejecutan en tu máquina, en local. Sin analítica sobre tu entrada, sin logs, sin viaje a la nube. El formato que seguimos es la especificación YAML 1.2.2. Para confirmar que no se sube nada, abre las DevTools y observa la pestaña Network mientras comparas.