Convertisseur JSON → YAML, gratuit

Comment ça marche

1. Collez du JSON : saisissez n'importe quel JSON valide, des paires clé-valeur plates aux objets et tableaux profondément imbriqués.
2. Conversion instantanée : l'outil transforme le JSON en YAML avec une indentation correcte, retire les guillemets des clés chaînes et traduit les types null, booléen et numérique.
3. Configurez la sortie : définissez la largeur d'indentation (2 ou 4 espaces) et choisissez entre le style bloc ou flux pour les collections.
4. Copiez le YAML : le résultat est prêt à coller dans des fichiers de configuration, des pipelines CI/CD ou des manifestes Kubernetes.

Pourquoi convertir du JSON en YAML ?

Le YAML est le format de configuration privilégié pour les outils d'infrastructure comme Kubernetes, Docker Compose, GitHub Actions, Ansible et les charts Helm, plus lisible que le JSON, il prend en charge les commentaires et n'exige pas de guillemets autour de chaque chaîne. Convertir des réponses d'API, des sections de package.json ou des structures de données de JSON à YAML est une tâche fréquente en DevOps et en développement back-end. La structure basée sur l'indentation du YAML est plus lisible pour les humains, tandis que le JSON est préféré pour les API et la génération programmatique, ce convertisseur fait le pont entre les deux.

Correspondance des types

• Chaînes → sans guillemets si possible, entre guillemets si elles contiennent des caractères spéciaux
• Nombres → scalaires numériques YAML tels quels
• Booléens → true / false en YAML
• null → null ou ~ en YAML
• Tableaux → séquences en bloc YAML avec préfixe -
• Objets → mappings YAML avec paires clé : valeur

Qu'est-ce que la conversion JSON vers YAML ?

La conversion JSON vers YAML traduit un arbre de paires clé-valeur d'un format de sérialisation à un autre tout en préservant les données sous-jacentes. Les deux formats décrivent la même forme de données (chaînes, nombres, booléens, null, tableaux, objets), mais JSON utilise des accolades et des crochets tandis que YAML utilise l'indentation et des tirets. La même configuration «name: app, version: 1, ports: 80, 443» peut être exprimée dans l'un ou l'autre, et les convertisseurs passent de l'un à l'autre sans perte de sens.

JSON, inventé par Douglas Crockford vers 2001 et standardisé comme RFC 4627 en 2006 et ECMA-404 en 2013, est la lingua franca des API web. YAML 1.0 (2001), 1.1 (2005) et 1.2 (2009) par Clark Evans, Ingy doet Net et Oren Ben-Kiki a été conçu comme un sur-ensemble de JSON optimisé pour la lisibilité humaine, avec prise en charge des commentaires, des chaînes multi-lignes, des ancres et alias. Les outils DevOps modernes (Kubernetes, Docker Compose, GitHub Actions, Ansible, Helm) ont opté par défaut pour YAML parce que les configs sont écrites et examinées par des humains.

Ce convertisseur associe les deux formats côte à côte. Collez JSON à gauche, cliquez sur JSON vers YAML, et le panneau de droite se met à jour avec du YAML valide à votre profondeur d'indentation choisie (2 ou 4 espaces). Le bouton inverse exécute le même processus à l'envers. La conversion utilise la bibliothèque js-yaml (Vitaly Puzrin, 2011) chargée depuis jsDelivr, qui implémente la spec YAML 1.2 avec suffisamment de précision pour faire un aller-retour des manifestes Kubernetes, des Helm charts et des spécifications OpenAPI.

Ce qu'il y a dans le convertisseur

L'interface utilise une mise en page en grille à deux panneaux : JSON à gauche, YAML à droite. Sur les écrans de moins de 768 pixels de large, la mise en page s'empile verticalement. Au-dessus des panneaux, un sélecteur d'indentation vous permet de choisir 2 ou 4 espaces par niveau. Le choix actif est surligné, et l'indentation s'applique aux deux sens de conversion.

Chaque panneau a ses propres boutons d'action. Le panneau JSON propose JSON vers YAML (convertir) et Effacer. Le panneau YAML propose YAML vers JSON (inverse), Copier (presse-papiers) et Télécharger .yaml (enregistrer comme fichier avec l'extension .yaml et l'encodage UTF-8). La bannière d'erreur sous le convertisseur fait remonter les erreurs d'analyse avec le numéro de ligne et un court message, afin que vous puissiez corriger une entrée invalide sans quitter l'outil.

Sous le capot, la conversion JSON vers YAML utilise JSON.parse plus la fonction dump de js-yaml. Le sens YAML vers JSON utilise la fonction load de js-yaml plus JSON.stringify avec un retrait de 2 espaces. Les deux directions sont des fonctions pures de l'entrée, aucun état n'est transmis entre les conversions, et rafraîchir la page réinitialise tout.

Histoire et contexte

Douglas Crockford spécifie JSON (2001)

Douglas Crockford a documenté la syntaxe JSON en avril 2001 alors qu'il était chez State Software, après avoir réalisé que la syntaxe littérale d'objet de JavaScript pouvait servir de format de données indépendant du langage. La spec était délibérément minimale : six types, deux collections, pas de commentaires, pas de schéma. RFC 4627 a suivi en 2006 et ECMA-404 en 2013. Le minimalisme est exactement ce qui a rendu JSON omniprésent sur le web.

YAML 1.0 publié (2001)

Clark Evans, Ingy doet Net et Oren Ben-Kiki ont publié YAML 1.0 en mai 2001, la même année que JSON. L'acronyme était à l'origine Yet Another Markup Language mais a été rétronommé YAML Ain't Markup Language pour préciser que YAML cible les données de configuration, pas le balisage de document. La spec 1.0 était ambitieuse, prenant en charge les ancres, les alias, les flux multi-documents, les tags personnalisés et les commentaires.

YAML 1.1 et le problème de la Norvège (2005)

YAML 1.1 (janvier 2005) a resserré la spec mais a conservé le fameux comportement de coercition booléenne où les chaînes yes, no, on, off, y, n, true, false, plus leurs variantes en majuscules, deviennent toutes des booléens. C'est le Problème de la Norvège : le code de pays ISO non cité NO devient le booléen false. Le bogue a mordu les premiers utilisateurs de Kubernetes jusqu'à ce que YAML 1.2 (2009) supprime les orthographes booléennes alternatives.

YAML 1.2 déclare JSON comme un sous-ensemble (2009)

YAML 1.2 (octobre 2009) a explicitement fait de JSON un strict sous-ensemble de YAML, donc tout document JSON valide est aussi un document YAML valide. C'était une victoire de conception majeure : les outils qui géraient YAML 1.2 pouvaient analyser JSON gratuitement, simplifiant l'implémentation des convertisseurs et des validateurs. La version encore utilisée dans la plupart des outils aujourd'hui est 1.2 ou un profil compatible 1.1.

Kubernetes livre des manifestes YAML (2015)

Kubernetes 1.0, publié par Google en juillet 2015, a défini les ressources de cluster (Pods, Deployments, Services) à l'aide de manifestes YAML. Le choix était motivé par la lisibilité pour les équipes ops habituées aux éditeurs de texte et au contrôle de version. Helm (2016) a ajouté le templating par-dessus, GitHub Actions (2018) a adopté YAML pour les workflows, et les playbooks Ansible (2012 à 2018) ont consolidé YAML comme le langage de config DevOps dominant.

js-yaml devient la bibliothèque JavaScript de facto (à partir de 2011)

Vitaly Puzrin a publié js-yaml en 2011 comme un portage JavaScript pur de PyYAML. Les versions suivantes (2.0 en 2014, 3.0 en 2015, 4.0 en 2021) ont suivi la spec YAML 1.2, ajouté des schémas pour se désinscrire des fonctionnalités dangereuses et atteint plus de 50 millions de téléchargements npm hebdomadaires. La bibliothèque est intégrée par webpack, parcel et esbuild pour tout travail YAML côté navigateur, et c'est ce que ce convertisseur utilise sous le capot.

Flux de travail pratiques

Rédaction de manifestes Kubernetes

Lorsque vous générez un Pod ou un Deployment via kubectl run --dry-run=client -o json, vous obtenez du JSON. Collez-le ici, cliquez sur JSON vers YAML, et vous avez un manifeste prêt à être commité dans git. La conversion préserve les specs imbriquées, les variables d'environnement et les limites de ressources exactement comme Kubernetes les lira.

Définitions de service Docker Compose

Un coéquipier vous envoie un extrait JSON pour un nouveau service. Collez-le, convertissez, et déposez le YAML dans votre docker-compose.yml. L'indentation à 2 espaces est la valeur par défaut de Compose, donc laissez l'option d'indentation à 2.

Workflows GitHub Actions

Lorsque vous échafaudez un workflow à partir d'un générateur de modèle basé sur JSON ou copiez une étape depuis une réponse d'API JSON, collez-le ici et convertissez. La sortie va directement dans .github/workflows/*.yml. Notez que GitHub Actions accepte également JSON dans certains champs, mais YAML est la forme canonique.

Playbooks Ansible

Les inventaires Ansible commencent souvent leur vie comme du JSON exporté depuis un CMDB ou une base de données d'actifs. Collez, convertissez en YAML, et vous avez un fichier hosts ou un en-tête de playbook qui correspond au style attendu par Ansible. Utilisez une indentation de 2 espaces pour correspondre au guide de style de la communauté Ansible.

Valeurs Helm chart

Un fournisseur livre des configurations d'échantillon JSON pour son Helm chart. Convertissez en YAML et déposez dans values.yaml. La conversion respecte les clés imbriquées (image.repository, image.tag, resources.limits.memory) exactement comme Helm les attend.

Specs OpenAPI 3

Swagger Editor exporte les specs OpenAPI à la fois en JSON et YAML. Lorsqu'un outil émet du JSON mais que votre équipe utilise YAML dans le contrôle de version (ou vice-versa), ce convertisseur est le moyen le plus rapide de changer de format sans démarrer Node, Python ou yq.

Pièges courants

Le problème de la Norvège (yes, no, on, off comme booléens)

Dans YAML 1.1, les chaînes yes, no, on, off, y, n, true, false (et leurs variantes en majuscules) sont toutes des booléens. Donc le code de pays ISO non cité NO devient le booléen false. js-yaml 4.x utilise par défaut YAML 1.2 qui ne traite que true et false comme booléens, mais les analyseurs YAML plus anciens peuvent encore trébucher. Citez explicitement les chaînes ambiguës si vous mélangez des versions d'outils.

Les tabulations ne sont pas une indentation YAML valide

YAML utilise des espaces, pas des tabulations, pour l'indentation. Si votre éditeur insère des tabulations par défaut, le YAML converti échouera à l'analyse dans Kubernetes, Helm ou tout chargeur YAML strict. Configurez votre éditeur pour utiliser 2 ou 4 espaces pour les fichiers .yaml et .yml, ou exécutez un linter (yamllint) avant de commiter.

Les ancres et alias ne survivent pas à la conversion JSON

YAML prend en charge les ancres (&name) et les alias (*name) pour réutiliser des valeurs. Lorsque vous convertissez YAML en JSON, les ancres sont étendues en ligne car JSON n'a pas d'équivalent. La conversion inverse JSON vers YAML ne réintroduira pas les ancres automatiquement. Si vous avez besoin d'ancres, écrivez-les à la main après la conversion.

Les chaînes multi-lignes nécessitent des indicateurs explicites

Une chaîne JSON avec des nouvelles lignes intégrées (Hello\nWorld) se convertit en YAML en utilisant le scalaire de bloc littéral (|) ou le scalaire de bloc plié (>). js-yaml choisit la bonne forme, mais si vous modifiez le résultat à la main, rappelez-vous que | préserve les nouvelles lignes et > les replie en espaces.

Les grands nombres perdent en précision

Les nombres JavaScript sont des flottants IEEE 754 64 bits, donc les entiers au-delà de 2 à la 53 (environ 9 quadrillions) perdent en précision lorsqu'analysés par JSON.parse. La conversion en YAML préserve la valeur avec perte, pas l'originale. Si vos données ont des identifiants de type BigInt, encodez-les comme chaînes en JSON avant de convertir.

Les commentaires sont perdus en YAML vers JSON

YAML prend en charge les commentaires #, JSON non. Lorsque vous convertissez YAML avec commentaires en JSON, les commentaires sont supprimés car JSON n'a pas de syntaxe pour eux. Si vous faites un aller-retour YAML via JSON pour le traitement, attendez-vous à perdre chaque ligne #. Des outils comme yq ou ruamel.yaml peuvent préserver les commentaires, mais le js-yaml conforme à la spec les abandonne.

Confidentialité et gestion des données

Toute la conversion s'exécute dans votre navigateur via la bibliothèque js-yaml intégrée à la page. Nous n'envoyons pas votre JSON ou YAML à un serveur, ne journalisons pas les entrées et n'exécutons pas d'analyses sur le contenu de vos conversions. Le bouton Copier utilise l'API Clipboard qui nécessite un geste utilisateur, et le bouton Télécharger .yaml utilise une URL de blob en mémoire, donc le fichier ne fait jamais d'aller-retour via le réseau.

Une fois la page chargée (y compris le fichier CDN js-yaml), l'outil fonctionne hors ligne. Vous pouvez vous déconnecter du réseau et convertir des configurations sensibles (clés API, URL de bases de données, noms de services internes) sans qu'aucune ne quitte votre appareil. Le fichier js-yaml est servi depuis jsDelivr avec un hachage Subresource Integrity, donc le bundle ne peut pas être échangé en silence.

Quand ne pas utiliser ce convertisseur

Streaming de mégaoctets de données

Le convertisseur charge toute l'entrée en mémoire, l'analyse et émet le résultat d'un seul coup. Pour les fichiers JSON ou YAML de plusieurs mégaoctets, utilisez yq ou jq dans un pipeline shell, ou un analyseur en streaming dans votre langage favori. Le navigateur n'est pas le bon outil au-dessus de 5 à 10 mégaoctets.

Données binaires dans JSON

Si votre JSON a des blobs binaires encodés en Base64 qui doivent être inspectés ou modifiés, la conversion en YAML ne les déballera pas. YAML prend en charge le binaire tagué (!!binary) que js-yaml gère, mais les octets restent en Base64. Utilisez un éditeur binaire dédié pour le travail au niveau octet.

Validation de schéma

Ce convertisseur vérifie que l'entrée est un JSON ou YAML valide, mais il ne valide pas contre un schéma (JSON Schema, OpenAPI, Kubernetes CRD, valeurs Helm). Si vous avez besoin de savoir si un manifeste Kubernetes est structurellement correct pour un cluster 1.28, exécutez kubectl --dry-run=server ou un outil comme kubeval ou kubeconform.

Refactorisation consciente du schéma

Si vous avez besoin de renommer un champ dans des centaines de fichiers YAML, ou de mettre à niveau une version d'API (apps/v1beta1 vers apps/v1), utilisez sed, ast-grep ou yq avec des requêtes de chemin explicites. Le convertisseur ne fait que transformer entre les formats, il ne modifie pas le contenu sémantique.

Plus de questions

JSON est-il plus sûr que YAML ?

Pour la sécurité, oui. yaml.load de PyYAML (avant 5.1) et les analyseurs permissifs similaires pouvaient exécuter du code arbitraire à partir d'entrées YAML non fiables via des objets Python tagués. JSON n'a pas une telle fonctionnalité, chaque analyseur JSON est sûr par conception. Les analyseurs YAML modernes (PyYAML 5.1+, js-yaml depuis 4.0) utilisent par défaut safe-load, donc l'écart s'est réduit, mais JSON reste le défaut plus sûr pour les entrées non fiables.

Pourquoi YAML a-t-il choisi l'indentation plutôt que les accolades ?

Les auteurs de YAML voulaient que les configs se lisent comme des plans, donc ils ont utilisé la même convention que la whitespace significative de Python. Les accolades et crochets sont du YAML valide (style de flux), mais le style de bloc avec indentation est le défaut parce qu'il scanne plus naturellement pour les humains éditant en texte brut. Le compromis est que l'espace blanc devient significatif, ce qui prend en piège les éditeurs qui rognent automatiquement les espaces en fin de ligne.

YAML est-il toujours un sur-ensemble strict de JSON ?

Depuis YAML 1.2 (2009), oui. Tout document JSON valide est aussi un document YAML 1.2 valide. YAML 1.1 avait quelques cas limites (nombres sexagésimaux, le problème de la Norvège) où la relation était plus lâche. js-yaml moderne utilise 1.2 par défaut, donc la propriété de sur-ensemble est vraie pour cet outil.

Pourquoi le YAML Kubernetes est-il si verbeux ?

Les manifestes Kubernetes ont une forme de premier niveau fixe (apiVersion, kind, metadata, spec) et la spec contient des objets imbriqués reflétant les structs Go internes de l'API. La verbosité est un effet secondaire du mapping d'une API orientée objet vers un format texte plat. Des outils comme Kustomize, Helm et Pulumi réduisent la verbosité, mais le YAML sous-jacent est ce que kubectl envoie réellement au cluster.

Puis-je faire un aller-retour JSON via YAML sans perte de données ?

Pour la plupart du JSON, oui. Les chaînes, nombres, booléens, null, tableaux, objets survivent tous. Les cas limites incluent les très grands entiers (perte de précision), les paires de substitution Unicode (dépend de l'analyseur) et l'ordre des clés (YAML peut réordonner). Si vos clés JSON doivent conserver leur ordre d'origine, utilisez un outil qui respecte l'ordre d'insertion (OrderedDict de Python, json-stable-stringify en JavaScript).

Qu'en est-il de TOML et HCL ?

TOML (Tom's Obvious Minimal Language, 2013 par Tom Preston-Werner) est utilisé par Cargo (Rust), pyproject.toml (Python) et d'autres. HCL (HashiCorp Configuration Language, 2014) est utilisé par Terraform. Les deux ciblent le cas d'utilisation de la configuration mais utilisent une syntaxe différente. Ce convertisseur ne gère que JSON et YAML. Pour TOML ou HCL, utilisez des convertisseurs dédiés ou yq avec le bon plugin.