Convertir un JSON en YAML

Comment ça marche

Vous avez une configuration JSON sortie d'une API ou d'une application, mais docker-compose, un workflow GitHub Actions ou un manifeste Kubernetes attend du YAML : collez le texte JSON dans le panneau de gauche, le YAML s'écrit à droite pendant que vous tapez. Chaque clé d'objet devient une ligne « clé: valeur », chaque tableau une suite de lignes « - élément » ; l'imbrication se lit à l'indentation, et cette indentation ne contient que des espaces, parce que YAML refuse la tabulation. Les chaînes de caractères s'écrivent sans guillemets ; seules celles qui changeraient de type en YAML sont mises entre guillemets doubles. Un "true", un "007", un "1e3" ou un "2024-01-05" qui sont du texte dans votre JSON deviendraient, écrits nus, un booléen, un nombre ou une date pour un lecteur YAML. La ligne de résultat indique combien de chaînes ont été protégées ainsi. Un texte sur plusieurs lignes sort en bloc « | », ligne par ligne ; les nombres gardent exactement leur écriture JSON (1e3, 1.0, avec le point décimal). Collez le résultat dans le fichier cible, par exemple docker-compose.yml ou .github/workflows/deploy.yml, ou téléchargez-le en .yaml. Pour le sens inverse, choisissez « YAML → JSON » : l'outil lit les correspondances et les listes en blocs, les chaînes entre guillemets, les collections [ ] et { } tenant sur une ligne, les blocs « | » et « > » et les commentaires ; les ancres, alias et balises de type ne sont pas pris en charge et sont signalés avec leur numéro de ligne. Dans ce sens, enregistrez le fichier téléchargé avec l'extension .json : le nom proposé au téléchargement est donnees.yaml dans les deux sens. Si le JSON n'est pas valide, la ligne et la colonne du problème sont indiquées en français.

Cet outil est aussi connu sous le nom de json vers yaml, convertir json en yaml, yaml vers json, json en yaml, json to yaml, yaml to json, convertisseur json yaml.

Qu'est-ce que JSON ?

JSON est le format texte que les programmes utilisent pour s'échanger des données ; sur cette page, vous le rencontrez surtout comme fichier de réglages exporté par une application ou comme réponse renvoyée par une API. Ses règles sont strictes, et cette rigueur vous rend service : chaque clé est entre guillemets doubles, les valeurs sont séparées par des virgules, il n'y a pas de ligne de commentaire et aucune virgule n'est tolérée après le dernier élément. On sait donc toujours avec certitude si un JSON est valide ; en cas d'erreur, l'outil indique la ligne et la colonne où il s'est arrêté. Les types sont explicites : 7 est un nombre, "7" est un texte. C'est cette distinction qu'il faut préserver au passage vers YAML, et c'est là que la décision des guillemets compte.

Qu'est-ce que YAML ?

YAML est un format de configuration conçu pour être lu et modifié à la main ; les fichiers de docker-compose, GitHub Actions, Kubernetes, Ansible et Home Assistant sont en YAML. La structure ne passe pas par des accolades mais par l'indentation : une ligne qui commence plus à droite que la précédente lui appartient, ce qui impose des espaces et interdit la tabulation. Les clés s'écrivent sans guillemets, un commentaire commence par #, et un texte sur plusieurs lignes se note tel quel derrière « | ». Le prix de cette lisibilité est l'ambiguïté : un no, un 007 ou un 2024-01-05 sans guillemets cessent d'être du texte chez certains lecteurs ; cet outil protège ces valeurs en les mettant entre guillemets.

Quelle est la différence entre JSON et YAML ?

Les deux transportent le même modèle de données : des correspondances clé-valeur, des listes et des valeurs simples. La différence tient à l'écriture et au lecteur visé. JSON est écrit pour la machine : accolades et guillemets obligatoires, aucun commentaire, une seule façon d'écrire chaque chose ; il se produit et se lit sans erreur, et c'est le format des réponses d'API et des fichiers de données. YAML est écrit pour l'humain : la structure se lit à l'indentation, les guillemets sont le plus souvent inutiles, on peut laisser des commentaires et un long texte s'écrit en bloc ; c'est le format des fichiers de configuration modifiés à la main. YAML 1.2 est aussi un sur-ensemble de JSON : un JSON valide est en même temps un YAML valide, et c'est pourquoi le sens YAML → JSON de cet outil accepte directement un texte JSON. La contrepartie est l'ambiguïté de type des valeurs YAML sans guillemets : en JSON, "true" et true sont deux choses distinctes ; en YAML, true écrit nu est un booléen. Le vrai travail de la conversion consiste à préserver cette distinction, et la ligne de résultat indique combien de chaînes ont été mises entre guillemets pour cela.

Pièges du YAML : tabulation, yes/no et 007 sans guillemets

En YAML, la structure se lit à l'indentation, et cette indentation n'accepte que des espaces. Une ligne indentée avec une tabulation est une erreur selon la norme ; c'est pour cela que cet outil ne propose pas de choix « tabulation ». Si un fichier YAML que vous avez sous la main renvoie « indentation incohérente », il y a le plus souvent une tabulation invisible en début de ligne : la commande « convertir les tabulations en espaces » de votre éditeur règle le problème.

Deuxième piège : la version. En YAML 1.1, yes, no, on et off écrits nus étaient des booléens ; YAML 1.2 les traite comme de simples chaînes. La clé « on: » d'un workflow GitHub Actions et le « restart: no » d'un docker-compose sont connus pour cela : un ancien lecteur transforme on en true et no en false. Dans le sens YAML → JSON, cet outil applique la règle 1.2 (yes reste une chaîne) ; dans le sens JSON → YAML, il met ces mots entre guillemets pour que la sortie reste du texte, quelle que soit la génération du lecteur qui la recevra.

Troisième piège : les chaînes qui changent de type dès qu'on retire les guillemets. En JSON, "007" est un texte ; en YAML, 007 sans guillemets vaut le nombre 7, 1e3 vaut mille et 2024-01-05 devient une date. L'outil met ces chaînes entre guillemets doubles et annonce leur nombre dans la ligne de résultat. La même règle s'applique à la chaîne vide (""), au texte qui commence ou finit par une espace, à toute valeur contenant « : » suivi d'une espace, et aux textes qui débutent par un signe qui a un sens en YAML : #, -, *, & entre autres.

Le texte sur plusieurs lignes sort en bloc « | » : sous l'en-tête « description: | », les lignes viennent indentées, et si le texte ne se termine pas par un saut de ligne, c'est « |- » qui est utilisé. Cette forme n'a besoin d'aucun caractère d'échappement ; c'est la plus lisible pour une liste de commandes ou une longue description.

Quel réglage pour quel cas : indentation, sens et nom de fichier

Pour l'indentation, prenez 2 espaces : tous les exemples docker-compose, GitHub Actions et Kubernetes sont écrits ainsi, et vos fichiers resteront cohérents avec ceux de votre équipe. Les 4 espaces ne servent que dans une structure très imbriquée, quand l'œil peine à voir à quel niveau appartient une ligne. Les deux réglages produisent un YAML valide ; seule la lisibilité change.

Le sens YAML → JSON a un périmètre volontairement étroit et annoncé : correspondances et listes en blocs, imbrication par indentation, chaînes avec ou sans guillemets, collections [a, b] et {a: 1} sur une seule ligne, blocs « | » et « > », commentaires et un seul en-tête de document « --- ». Ne sont pas pris en charge : les ancres et alias (&base, *base), les balises de type (!!str), les clés complexes commençant par « ? », une valeur entre guillemets ou en style flux étalée sur plusieurs lignes, et plusieurs documents dans un même texte. Si l'un d'eux est présent, l'outil le dit avec le numéro de ligne ; il ne produit jamais une sortie fausse en silence. Pour convertir un fichier qui utilise un alias, recopiez d'abord à la main la valeur que l'alias désigne.

Le nom proposé au téléchargement est donnees.yaml dans les deux sens. Vous pouvez enregistrer la sortie JSON → YAML en .yaml ou en .yml : c'est le même format ; docker-compose.yml et GitHub Actions utilisent .yml, Kubernetes le plus souvent .yaml. Dans le sens YAML → JSON, terminez le nom du fichier téléchargé par .json ; la ligne de résultat vous le rappelle à chaque fois.

Questions fréquentes

Comment convertir un fichier JSON en YAML ?

Ouvrez le fichier JSON dans un éditeur de texte, copiez son contenu et collez-le dans le panneau de gauche de cette page ; le YAML se forme aussitôt dans le panneau de droite. Vous pouvez copier la sortie et la coller dans le fichier cible (docker-compose.yml, fichier de workflow) ou la télécharger en .yaml. Il n'y a pas de fichier à déposer : le texte suffit.

Puis-je convertir du YAML en JSON sur cette page ?

Oui, mettez « Sens de la conversion » sur « YAML → JSON ». Les correspondances et listes en blocs, les chaînes entre guillemets, les collections sur une ligne, les blocs « | » et « > » et les commentaires sont lus. Les ancres et alias, les balises de type et les documents multiples ne sont pas pris en charge ; si une telle structure est présente, la ligne concernée est indiquée. Enregistrez le fichier téléchargé avec l'extension .json.

Pourquoi certaines valeurs sortent-elles entre guillemets ?

Parce que, écrites sans guillemets, un lecteur YAML les prendrait pour autre chose que du texte : "true" deviendrait un booléen, "007" le nombre 7, "1e3" mille, "2024-01-05" une date, et "yes" un true chez les anciens lecteurs (YAML 1.1). La chaîne vide, un texte avec une espace au début ou à la fin, et les valeurs contenant des signes YAML comme #, - ou « : » sont protégées pour la même raison. La ligne de résultat indique combien de chaînes sont concernées ; les guillemets ne modifient pas la donnée, ils la préservent.

Les données que je colle sont-elles envoyées à un serveur ?

Non. L'analyse et la production du YAML se font entièrement dans votre navigateur ; même si vous collez une configuration contenant un mot de passe de base de données ou une clé d'API, le texte ne quitte pas cette page et n'est enregistré nulle part.