Collez deux documents YAML et obtenez un diff précis côte à côte. Conçu pour les manifests Kubernetes, les workflows GitHub Actions, les valeurs Helm et les fichiers docker-compose.
Un outil gratuit dans le navigateur pour comparer deux documents YAML. Collez l'ancienne version à gauche, la nouvelle à droite, et les différences sont mises en évidence caractère par caractère. Le texte ne quitte jamais votre navigateur, ce qui compte quand vous diffez des manifests qui contiennent des références à des secrets ou des hostnames internes.
Le diff travaille au niveau caractère, le même moteur que notre outil de diff de texte. Le mode YAML de l'éditeur gère la coloration syntaxique selon la spécification YAML 1.2.2, donc vos block scalars, anchors et flow collections sont colorés correctement.
Si vous avez déjà fixé un diff de 400 lignes d'un values.yaml Helm dans une pull request en cherchant le décalage d'indentation qui a cassé le chart, c'est l'outil qui le retrouve en quelques secondes. Pratique aussi quand un copier-coller entre Slack et votre éditeur transforme des espaces en tabs, ce que YAML refuse catégoriquement.
Le diff s'exécute au niveau caractère, puis une passe de nettoyage sémantique regroupe les surlignages en blocs cohérents au lieu de caractères dispersés. Les insertions apparaissent en vert dans le panneau de droite, les suppressions en rouge à gauche, et les compteurs dans chaque en-tête indiquent le nombre d'éditions distinctes trouvées par le diff.
YAML a des règles d'analyse qui mordent ceux qui le prennent pour un format indulgent. L'indentation est structurelle selon la spec YAML 1.2.2, donc un seul espace mal placé change l'arbre du document. Les tabs sont interdits comme indentation, et le parseur les rejette d'office. Le typage implicite transforme le token non quoté NO en booléen false en YAML 1.1, c'est le fameux Norway problem : les listes de codes pays perdent silencieusement la Norvège. YAML 1.2 a resserré les règles pour que seuls true, false, null et les formes numériques se convertissent sans guillemets, mais beaucoup d'outils analysent encore en 1.1.
Si vous avez déjà converti votre YAML en JSON pour un consommateur en aval, notre outil de diff JSON traite les questions structurelles comme l'ordre des clés et la canonicalisation. JSON est un sous-ensemble strict de YAML 1.2, donc tout document JSON valide est aussi un YAML valide : cette compatibilité est documentée dans la spec et c'est pourquoi js-yaml et libyaml peuvent tous deux faire un round-trip JSON sans surprise.
Deux panneaux de texte, un diff. Pas d'inscription, pas d'envoi, pas d'aller-retour serveur.
Collez l'ancien YAML à gauche, le nouveau à droite. Ou cliquez sur Téléverser de l'un ou l'autre côté pour charger directement un fichier .yaml ou .yml. Le bouton Exemple remplit les deux panneaux avec un petit Deployment Kubernetes pour voir l'outil en action d'abord.
YAML utilise uniquement des espaces pour l'indentation, jamais de tabs. Si vous avez collé depuis un client de chat ou un terminal qui a converti les espaces en tabs, le parseur rejettera le fichier. L'éditeur surligne les tabs et les espaces en fin de ligne pour que vous les repériez avant qu'ils ne fassent échouer un déploiement.
Les suppressions apparaissent en rouge à gauche, les insertions en vert à droite. Les deux panneaux défilent ensemble pour suivre de longs manifests sans perdre le fil. Les compteurs de changements dans chaque en-tête résument le nombre d'éditions distinctes trouvées par le diff.
Lancez kubectl get deployment web -o yaml dans les deux clusters et diffez la sortie. Souvent prod a encore replicas: 2 et un vieux tag d'image parce qu'un rollout de fin de sprint n'a jamais abouti, et un diff de texte est le moyen le plus rapide de le confirmer avant de relancer kubectl apply. Le modèle d'objets Kubernetes est du YAML de bout en bout, donc c'est le cas du quotidien.
Quand un workflow ne se déclenche plus après un renommage de branche ou qu'un job prend soudain 8 minutes de plus, diffez .github/workflows/ci.yml contre le dernier commit vert. Le coupable est en général un filtre on: modifié, une clé cache: retirée dans actions/setup-node, ou une entrée de matrice qui est passée discrètement de node-version: "18" (string) à node-version: 18 (nombre) et a fait tomber le type checker.
Diffez docker-compose.yml contre la version dans main pour vérifier quelles entrées environment: ont vraiment changé. Les gens collent une liste de nouvelles variables et oublient que l'une d'elles était déjà définie sous un autre service, et l'override bascule en silence un flag ailleurs. Le diff le rend évident.
Lors d'un upgrade de chart de 1.8.0 à 2.0.0, diffez votre values.yaml contre les nouveaux defaults publiés par le mainteneur. Helm fusionne les valeurs clé par clé, donc une clé de niveau supérieur renommée (image.tag qui passe sous image.repository) retombe silencieusement sur le default du chart. Le diff fait remonter le rename avant que helm upgrade ne déploie une régression.
Un diff d'openapi.yaml de 3 000 lignes est illisible quand un générateur de code réordonne les paths par ordre alphabétique. Comparez les versions côte à côte et le vrai changement ressort : un champ required ajouté à un schéma de requête, ou une réponse dont le type est passé en silence de string à integer. Plus simple que de fouiller un SDK généré pour trouver pourquoi la build s'est cassée.
Quand un playbook fonctionne en dev et échoue en prod, diffez l'inventaire ou le defaults/main.yml du role entre les deux. Une cause fréquente est une hostvar jamais recopiée, ou un become: yes mis sur le role en dev mais sur une seule task en prod. Le diff le repère en quelques secondes.
Une courte fiche pour les cas limites d'analyse que cet outil fait remonter le plus souvent. Tout est ancré dans la spécification YAML et le comportement réel des parseurs.
| Topic | What this tool does |
|---|---|
| Indentation | Espaces uniquement, et le compte est structurel. Deux et quatre espaces sont courants ; choisissez-en un par fichier et tenez-vous-y. La page YAML sur Wikipédia a un bon résumé si vous voulez l'historique. |
| Tabs | Interdits en indentation par la spec. Autorisés à l'intérieur des valeurs scalaires. Si votre éditeur insère un tab à Entrée, configurez-le pour utiliser des espaces sur les fichiers .yaml et .yml. |
| Anchors et aliases | &name définit un anchor ; *name le référence. Pratique pour répéter de gros blocs comme les env vars d'un container ou la configuration par défaut d'un service sans copier-coller. |
| Merge keys | <<: *base fusionne le mapping référencé dans le courant. Une fonctionnalité YAML 1.1. La plupart des parseurs, dont libyaml, l'acceptent toujours ; la spec YAML 1.2 l'a retirée. |
| Fichiers multi-document | Trois tirets (---) séparent les documents dans un même flux. Pratique pour passer plusieurs objets Kubernetes par un seul kubectl apply -f. ... termine un document. |
| Block scalars | | conserve les sauts de ligne (literal) ; > les replie en espaces. Les modificateurs - et + contrôlent les sauts de ligne en fin. Utilisez | pour des scripts shell, > pour de la prose longue. |
| Le Norway problem | Sans guillemets, NO, YES, ON, OFF deviennent des booléens en YAML 1.1. Mettez-les entre guillemets ou utilisez un parseur 1.2. Voir les définitions de types YAML pour la liste des chaînes converties. |
| Encodage | UTF-8 est requis par la spec YAML 1.2. UTF-16 est autorisé avec un BOM. En pratique, les outils attendent de l'UTF-8 sans BOM, donc enregistrez vos fichiers ainsi pour éviter les surprises. |
YAML est sensible aux espaces, donc un diff de texte ordinaire est déjà utile : tout changement d'indentation est un changement structurel et le diff l'attrape. La différence est dans la présentation. Le mode YAML colore les anchors, tags, block scalars et flow collections avec les couleurs de la syntaxe, donc on voit d'un coup d'œil si le changement porte sur une clé, une valeur string ou un élément de liste. L'algorithme de diff sous-jacent est le même que celui de notre outil de diff de texte.
Parce que l'indentation est la seule chose qui dit au parseur quelles clés appartiennent à quel mapping. La spec YAML 1.2.2 définit le niveau d'indentation d'un nœud par le nombre d'espaces en début de ligne, et interdit les tabs en indentation. Un seul espace de plus promeut une clé dans un sous-mapping. Cette rigueur est le prix à payer pour un format qui n'a besoin ni d'accolades ni de virgules, et c'est pourquoi on voit plus de bugs d'indentation en YAML qu'en JSON.
Le typage implicite de YAML 1.1 transforme le token non quoté NO en booléen false. Donc une liste de codes pays qui inclut NO pour la Norvège devient en silence une liste avec une entrée remplacée par false. Pareil pour YES, ON, OFF et leurs voisins. StrictYAML le documente en détail. Le correctif : mettre la valeur entre guillemets ("NO") ou utiliser un parseur conforme à YAML 1.2, qui ne convertit implicitement que true, false et null.
Un anchor (&name) marque un nœud pour le référencer plus tard avec un alias (*name), évitant des répétitions dans les fichiers longs. La merge key (<<: *name) était une extension YAML 1.1 qui copie toutes les clés du mapping référencé dans celui en cours, utile pour partager une configuration commune entre services. Les merge keys ne font pas partie de YAML 1.2, mais la plupart des parseurs, dont js-yaml, les acceptent toujours par compatibilité. Le diff traite anchors et aliases comme du texte brut, donc un anchor renommé apparaît proprement.
Oui. JSON est un sous-ensemble strict de YAML 1.2, donc tout document JSON valide est aussi un document YAML valide. Vous pouvez mélanger les deux si vous y tenez, en glissant une flow collection façon JSON dans un fichier en style bloc. Pour du JSON pur, notre outil de diff JSON a des boutons formater et valider spécifiques au JSON, dont le pretty-print et le tri des clés.
Parce que la spec YAML interdit les tabs en indentation. Citation de la spec 1.2.2 : "To maintain portability, tab characters must not be used in indentation." Les tabs sont autorisés à l'intérieur des valeurs scalaires (un string peut contenir un tab), juste pas en début de ligne, là où l'indentation est mesurée. Le correctif : un rechercher-remplacer rapide de tab vers deux ou quatre espaces, selon la convention déjà en place dans votre fichier.
Votre YAML ne quitte jamais votre navigateur. L'éditeur, le coloriseur de syntaxe et le diff s'exécutent tous sur votre machine, en local. Pas d'analytique sur votre saisie, pas de logs, pas d'aller-retour vers le cloud. Le format que nous suivons est la spécification YAML 1.2.2. Pour vérifier que rien n'est envoyé, ouvrez les DevTools et regardez l'onglet Network pendant que vous comparez.