Convertisseur JSON ↔ YAML

RSS

Convertissez du JSON en YAML ou du YAML en JSON en un clic, pour Kubernetes, Docker Compose, les pipelines CI et les spécifications OpenAPI.

Fonctionne à 100 % dans votre navigateur. Rien de ce que vous collez n'est envoyé ni stocké.
JSON ou YAML en entrée
Résultat
Prêt.

Comment utiliser le convertisseur JSON ↔ YAML

  1. Choisissez le sens : JSON → YAML ou YAML → JSON.
  2. Collez votre document dans la zone de saisie, ou tapez-le directement.
  3. Le résultat converti apparaît instantanément. Si l'entrée est invalide, le message d'erreur indique la ligne qui n'a pas pu être analysée.
  4. Copiez le résultat dans votre manifeste, votre fichier de pipeline ou votre client d'API.

La conversion s'exécute entièrement dans votre navigateur : les fichiers de configuration contenant des noms d'hôte internes ou des identifiants ne sont donc jamais envoyés ni stockés sur nos serveurs.

JSON et YAML : les mêmes données, deux notations

JSON (JavaScript Object Notation) et YAML (YAML Ain't Markup Language) décrivent les mêmes structures de base : des mappings (objets avec des paires clé-valeur), des séquences (tableaux) et des scalaires (chaînes, nombres, booléens et null). Depuis YAML 1.2, tout document JSON valide est aussi un document YAML valide, c'est pourquoi la conversion de JSON en YAML se fait sans perte. Dans l'autre sens, c'est généralement sans perte aussi, mais YAML possède des fonctionnalités que JSON n'a pas, comme les commentaires, les ancres et les chaînes multilignes en bloc, qui sont aplaties ou supprimées quand vous produisez du JSON.

Les développeurs passent sans cesse de l'un à l'autre :

  • Les manifestes Kubernetes sont normalement écrits en YAML, alors que kubectl get -o json et l'API elle-même parlent JSON.
  • Les fichiers Docker Compose (compose.yaml) sont en YAML ; les convertir en JSON aide quand on les génère à partir de scripts.
  • GitHub Actions et la plupart des systèmes d'intégration continue définissent leurs workflows en YAML.
  • Les spécifications OpenAPI peuvent s'écrire dans l'un ou l'autre format, et de nombreux outils acceptent les deux.

Voici le même objet dans les deux notations :

{"service": "web", "replicas": 3, "ports": [80, 443], "debug": false}
service: web
replicas: 3
ports:
  - 80
  - 443
debug: false

Pièges courants de YAML

Le « problème de la Norvège »

YAML 1.1 traite les valeurs non entre guillemets yes, no, on, off, y et n (avec différentes casses) comme des booléens. Une liste de codes pays transforme donc la Norvège en false dans les analyseurs qui suivent YAML 1.1 :

countries:
  - GB
  - NO     # YAML 1.1 : false   schéma de base YAML 1.2 : "NO"
  - SE

YAML 1.2 limite les booléens à true et false, mais de nombreuses bibliothèques très utilisées appliquent encore par défaut le comportement de la version 1.1. La bonne habitude est de mettre entre guillemets toute chaîne qui pourrait être prise pour un autre type : "NO", "on", "1.10", "0755". Les numéros de version sont un piège classique : 1.10 sans guillemets devient le nombre 1.1.

Indentation

YAML utilise l'indentation pour exprimer l'imbrication, et les tabulations sont interdites pour indenter. Une seule espace mal alignée change la structure ou empêche l'analyse :

spec:
  containers:
    - name: app
      image: nginx
     ports:          # une espace de moins : erreur d'analyse
        - containerPort: 80

Ancres et alias

YAML permet de définir un bloc une seule fois avec &name et de le réutiliser avec *name, souvent combiné à la clé de fusion <<. JSON n'a pas d'équivalent, le convertisseur développe donc chaque alias en une copie complète :

defaults: &defaults
  restart: always
  logging: json
web:
  <<: *defaults
  image: nginx

Notez que la clé de fusion est une extension de YAML 1.1 ; tous les analyseurs ne la prennent pas en charge.

Conseils pour des conversions propres

  • Les commentaires (# ...) sont supprimés lors de la conversion de YAML en JSON, car JSON n'a pas de syntaxe de commentaire. Gardez le fichier YAML comme source de référence si les commentaires comptent.
  • Les chaînes multilignes en bloc (| conserve les retours à la ligne, > les replie en espaces) deviennent des chaînes ordinaires avec des séquences d'échappement \n en JSON.
  • Les grands entiers au-delà de 253 peuvent perdre en précision dans les outils fondés sur JavaScript. Mettez entre guillemets les identifiants qui doivent rester exacts.
  • Pour peaufiner davantage le résultat, passez-le dans le Formateur et validateur JSON ou le Formateur et validateur YAML.
Astuce : Un fichier peut contenir plusieurs documents YAML séparés par ---, comme le font souvent les lots Kubernetes. JSON n'a pas cette notion : divisez donc les fichiers multi-documents avant de les convertir, ou attendez-vous à n'obtenir qu'un seul document en sortie.

Questions fréquentes

Tout fichier JSON est-il un YAML valide ?

Avec YAML 1.2, oui : il a été conçu comme un sur-ensemble de JSON. Vous pouvez donner du JSON tel quel à la plupart des analyseurs YAML. Le convertir en YAML par blocs le rend simplement plus facile à lire et à modifier.

Pourquoi la valeur de mon YAML a-t-elle changé de type après la conversion ?

Les scalaires sans guillemets sont interprétés par l'analyseur. Des valeurs comme no, off, 1e3, 0x1F ou 2024-01-01 peuvent devenir des booléens, des nombres ou des dates selon la version de YAML et la bibliothèque. Mettez-les entre guillemets pour les conserver comme chaînes.

Puis-je utiliser des tabulations en YAML ?

Non. La spécification YAML interdit les tabulations pour l'indentation. Utilisez des espaces, en général deux par niveau, et configurez votre éditeur pour qu'il insère automatiquement des espaces.

Les commentaires survivent-ils à un aller-retour ?

Non. Les commentaires disparaissent dès que le YAML est converti en JSON, et ils ne peuvent pas être récupérés lors de la conversion inverse. Gardez les commentaires dans le fichier YAML d'origine.

Mis à jour

Copié dans le presse-papiers