Aller au contenu principal
ToolsByUs

JSON vs YAML

JSON est le format d’échange : strict, sans commentaires, compris par toutes les API et tous les parseurs. YAML est le format de configuration humaine : délimité par l’indentation, accueillant pour les commentaires, éditable à la main. Choisissez JSON pour des programmes qui se parlent et YAML pour des personnes qui écrivent à des programmes — et convertissez sans perte dans les deux sens.

100 % local

JSON vs YAML en clair

Les deux formats sont souvent présentés comme rivaux, ce qui masque la vérité utile : ils résolvent des problèmes différents, et la plupart des projets réels emploient les deux. JSON a gagné l’échange de données parce que sa grammaire tient sur une carte d’index et parce qu’une charge utile émise par un service peut être consommée par un autre sans configuration partagée. YAML a gagné la configuration parce que ceux qui l’éditent sont des humains dans un éditeur de texte, et que les humains veulent des commentaires, des listes lisibles et la liberté de se passer de guillemets.

Le coût de cette douceur humaine est une spécification que les propres auteurs de YAML décrivent comme compliquée : l’indentation porte du sens, le type d’un scalaire nu est inféré (et l’échec classique est une valeur comme `no` qui devient silencieusement le booléen false), et un fichier peut s’analyser en disant quelque chose que son auteur n’a jamais voulu. La rigueur de JSON est exactement ce qui le rend ennuyeux — un nombre est un nombre, une chaîne est une chaîne, et aucun éditeur ne peut reformater votre fichier en un document différent.

La comparaison ci-dessous reste au niveau où les compromis mordent réellement : règles de syntaxe, comportement de typage, commentaires, taille, et l’outillage que chaque format suppose. Quand il faut passer de l’un à l’autre, les deux sens ont leurs convertisseurs honnêtes sur ce site — et comme tout ici, ils s’exécutent entièrement dans votre navigateur.

Mettre la config en tableau pour une revue en tableur est une étape courante, et le convertisseur YAML vers CSV le fait sans quitter l’onglet.

Besoin de la conversion exacte que compare cette page ? Le convertisseur YAML vers JSON exécute le cycle d’analyse et d’émission dans votre navigateur, sans aucun envoi.

Syntaxe : ponctuation contre indentation

La grammaire de JSON emploie six caractères structurants — crochets, accolades, deux-points et virgule — si bien que l’imbrication d’un document se voit dans sa ponctuation et qu’un linter peut pointer le caractère exact qui cloche. YAML dépense son budget de ponctuation en lisibilité : l’imbrication est l’indentation, les listes sont des tirets, et les paires clé/valeur n’exigent d’autre séparateur qu’un deux-points et une espace. Résultat : un document JSON de cinq lignes devient deux lignes de YAML, et un document profondément imbriqué raccourcit de façon spectaculaire — au prix d’une classe d’erreurs entière que JSON n’a pas, l’échec du mauvais nombre d’espaces, que certains parseurs signalent sur une ligne qui n’a rien à voir avec votre erreur.

AspectJSONYAML
Marqueur de portéeAccolades et crochetsIndentation (espaces uniquement)
CommentairesAucun — retirés par conception# jusqu’à la fin de ligne
GuillemetsObligatoires sur chaque chaîneOptionnels pour la plupart des scalaires
Chaînes multilignesÉchappements \n uniquementScalaires en bloc (| et >)
Ancres / réutilisationAucunAncres & et alias *
Taille de grammaireTient sur une page (RFC 8259)En plusieurs étapes, d’une complexité notoire

Types : stricts contre inférés

Chaque valeur JSON se déclare : les chaînes portent des guillemets, les nombres sont nus, les booléens sont exactement true et false. YAML, lui, infère. Un yes, no, on, off, true ou false nu est un booléen ; un 2026-09-19 nu est une date ; et une valeur comme 1.20 peut devenir silencieusement le nombre 1.2 selon le lecteur. Cet échec porte un nom dans la communauté — le problème de la Norvège, du fait que des codes pays comme NO deviennent le booléen false — et c’est l’argument le plus fort pour mettre des guillemets de manière défensive en YAML, même quand le parseur ne l’exige pas.

Le revers est délibéré : YAML veut des fichiers de configuration où 8080 se lit comme un numéro de port sans cérémonie. JSON veut l’échange, où l’émetteur et le consommateur doivent se mettre d’accord sur chaque octet, et où l’inférence est un bug. Chaque format est optimisé pour le lecteur auquel il s’attend.

Taille, performances et outillage

YAML est généralement le fichier le plus court et l’analyse la plus lente : le balayage d’indentation, les scalaires en bloc multilignes et la résolution d’ancres coûtent tous plus cher que la grammaire de JSON en une seule passe. Pour une configuration lue une fois au démarrage, c’est sans importance ; pour un format sur le fil diffusé des millions de fois par jour, c’est exactement pourquoi YAML n’a jamais délogé JSON du fil. L’outillage est l’autre asymétrie — chaque langage embarque un parseur JSON dans sa bibliothèque standard, tandis que les parseurs YAML sont des bibliothèques tierces aux différences réelles dans ce qu’ils acceptent, voilà pourquoi ce convertisseur documente le sous-ensemble qu’il prend en charge au lieu de promettre la spécification complète.

  • Taille de charge utile : YAML gagne sur les fichiers écrits à la main ; JSON minifié gagne souvent sur le fil, parce que ses règles de guillemets se compressent de façon prévisible.
  • Messages d’erreur : les parseurs JSON pointent le caractère fautif ; les parseurs YAML pointent la ligne où l’indentation a cessé de coïncider.
  • Interopérabilité : JSON est le défaut partout — pipelines de logs, API HTTP, stockage du navigateur. YAML est le défaut dans Kubernetes, les pipelines CI et Ansible.
  • Allers-retours : JSON→YAML→JSON est sans perte avec une paire conforme. YAML→JSON peut perdre des données dès que le fichier a employé des caractéristiques que JSON n’a pas — ancres, documents multiples ou clés non chaînes.

Quand choisir lequel

La décision est rarement une affaire de préférence et généralement une affaire de lecteur. Choisissez JSON quand un programme produit le document et qu’un autre programme le consomme : charges utiles d’API, logs structurés, état stocké, tout ce qui franchit une frontière de confiance. Choisissez YAML quand un humain écrit et maintient le document : pipelines CI, manifestes Kubernetes, fichiers docker-compose, toute config où un relecteur doit lire un diff et le comprendre sans décoder la ponctuation.

Et la recommandation s’inverse proprement : si vous vous surprenez à formater du JSON à la main avec quinze niveaux d’imbrication, ce fichier veut probablement être du YAML. Si vous vous trouvez en train d’analyser du YAML à l’exécution dans un service, ce fichier veut probablement être du JSON. Les convertisseurs liés ci-dessous font de la traversée une étape en un clic plutôt qu’un projet de migration.

Questions fréquentes

YAML est-il un surensemble de JSON ?

YAML 1.2 a explicitement rendu la plupart des documents JSON valides en YAML — un fichier JSON avec ses accolades intactes s’analyse généralement en YAML sans changement. L’inverse n’est jamais vrai : commentaires, ancres, clés nues et chaînes multilignes n’ont pas de représentation JSON. Le chemin de migration est donc unidirectionnel par conception, et les outils qui prétendent à une fidélité YAML→JSON complète choisissent en silence un sous-ensemble.

Quel format s’analyse le plus vite ?

JSON, avec une marge large et constante. Sa grammaire est en une seule passe, sans état d’indentation ; les scanners YAML suivent le contexte de colonne, résolvent les scalaires en bloc et déploient les ancres. Pour une configuration lue au démarrage, la différence se compte en millisecondes et n’a pas d’importance ; pour du trafic machine à machine à fort volume, c’est l’une des deux raisons pour lesquelles JSON tient le fil (l’autre étant le soutien universel des bibliothèques standard).

Pourquoi les systèmes CI et Kubernetes emploient-ils YAML plutôt que JSON ?

Parce que leurs documents sont écrits et relus par des humains. Les commentaires de YAML permettent à un manifeste de s’expliquer en ligne, l’indentation garde lisibles les spécifications de ressources profondément imbriquées, et les diff montrent clairement l’intention. Les mêmes propriétés qui rendent YAML risqué pour l’échange — inférence, sensibilité à l’indentation — sont des forces pour une config maintenue à la main.

Qu’est-ce que le problème de la Norvège en YAML ?

Plusieurs parseurs YAML attribuent un type aux scalaires nus par inférence, si bien qu’un code pays comme NO (Norvège) s’analyse en booléen false, et que off ou on deviennent aussi des booléens. Le remède : mettre entre guillemets toute valeur qui doit rester une chaîne. JSON est immunisé par construction — sans guillemets signifie nombre ou booléen, entre guillemets signifie chaîne, sans étape d’inférence où se tromper.

Convertir du YAML en JSON peut-il perdre des données ?

Oui, dans trois cas documentés : documents multiples dans un même fichier (seul le dernier survit à un convertisseur mono-document), ancres et alias (ils doivent être déployés, ce qui duplique le contenu), et clés non chaînes. Les convertisseurs de ce site rejettent ou signalent clairement ces cas au lieu de remodeler le document en silence.

Faut-il indenter YAML avec 2 ou 4 espaces ?

Les deux sont valides — YAML interdit les tabulations, pas un nombre d’espaces — mais 2 espaces est la convention écrasante dans les écosystèmes Kubernetes, CI et Docker, et mélanger les largeurs dans un même fichier, c’est ainsi que naissent les erreurs d’indentation. Choisissez 2, faites-le respecter par votre éditeur, et chaque diff restera lisible.

Où puis-je lire les normes citées ici ?

  • RFC 8259 — Le format d’échange de données JavaScript Object Notation (JSON)
  • YAML 1.2 — Spécification YAML, version 1.2 (révision 1.2.2)
Équipe ToolsByUs · Comment nous vérifions nos outils