YAML vers JSON

Oui, entièrement. Pas d’inscription, pas de compte, pas de limite d’utilisation et pas de paywall. Chaque fonctionnalité de cette page est disponible pour tout le monde, à chaque fois.

Non. La conversion s’exécute dans votre navigateur en JavaScript. Votre YAML n’est jamais transmis nulle part — il n’y a ni point de terminaison de conversion côté serveur, ni journalisation, ni analyse du contenu que vous collez. Vous pouvez le vérifier en ouvrant l’onglet Réseau pendant la conversion, ou en coupant internet : la page continue de fonctionner.

Non. C’est un convertisseur YAML vers JSON en ligne : il tourne dans l’onglet que vous avez déjà ouvert, sans téléchargement, sans outil en ligne de commande et sans extension. Tout convertisseur en ligne doit décider où la conversion a réellement lieu — la plupart envoient votre document à leur serveur, celui-ci le garde sur votre machine. Si vous préférez scripter la conversion, le guide « Convertir YAML en JSON dans du code » couvre la ligne de commande, Python, Node.js et Go.

Aucun plafond artificiel. La conversion se fait sur votre propre machine, la limite pratique est donc la mémoire de votre appareil. Des fichiers de quelques mégaoctets se convertissent sans problème ; de très gros documents peuvent brièvement figer la page pendant l’analyse.

Oui. Utilisez le bouton d’inversion entre les deux volets pour changer de sens sans quitter la page, ou rendez-vous sur le convertisseur JSON vers YAML dédié. L’inversion reprend la sortie courante comme nouvelle entrée, vous pouvez donc faire l’aller-retour avec un document.

Ils sont supprimés, parce que JSON n’a aucune syntaxe pour les commentaires. Le convertisseur vous indique combien ont été retirés plutôt que de les jeter en silence. Si vous devez les conserver, utilisez le formateur YAML, qui remet le YAML en forme sur place et les préserve.

Les fichiers qui séparent les documents par --- sont entièrement pris en charge. Vous pouvez les sortir en tableau JSON contenant tous les documents, ou en JSON Lines (NDJSON) avec un objet JSON compact par ligne, le format attendu par kubectl et la plupart des pipelines de logs. Les manifestes Kubernetes et les sorties Helm sont typiquement multi-documents.

Oui. Les ancres (&nom) et les alias (*nom) sont développés en leurs valeurs complètes, puisque JSON ne sait pas exprimer une référence. Les clés de fusion (<<) sont résolues par défaut, ce dont dépendent les fichiers Docker Compose, GitLab CI et Ansible. Vous pouvez désactiver la résolution si vous préférez voir la clé << brute.

YAML 1.2 traite les valeurs sans guillemets comme no, yes, on et off comme de simples chaînes. YAML 1.1 les traite comme des booléens — country: no devient donc false. YAML 1.1 lit aussi 022 comme l’octal 18 et 12:30 comme le nombre 750 en base 60. Ce convertisseur utilise YAML 1.2 par défaut et vous avertit dès qu’une valeur de votre document serait lue différemment en 1.1.

Les deux causes les plus fréquentes sont une tabulation utilisée pour indenter, ce que YAML interdit totalement, et une valeur sans guillemets contenant un deux-points, comme title: foo: bar. Les crochets et guillemets non fermés apparaissent aussi comme des erreurs d’indentation dans la plupart des analyseurs ; ce convertisseur les détecte spécifiquement et pointe le délimiteur qui n’a jamais été fermé.

Oui. Si le document ne peut pas être analysé, vous obtenez une description claire du problème, la ligne et la colonne exactes, une correction suggérée et un marqueur sur la ligne fautive dans l’éditeur. La page dédiée Validateur YAML est le même moteur avec le volet de sortie centré sur le diagnostic.

Une fois chargée, oui. Tout ce qu’il faut pour convertir est déjà dans votre navigateur, l’outil continue donc de fonctionner si vous perdez la connexion.

Collez votre YAML dans le volet de gauche du convertisseur en haut de cette page — il convertit le YAML en JSON en ligne, dans votre navigateur, au fil de la frappe, donc pas de bouton à presser et rien n’est envoyé. Réglez l’indentation sur 2 espaces, 4 espaces, tabulations ou minifié, triez éventuellement les clés, puis copiez le JSON ou téléchargez-le en fichier .json. Si le document ne s’analyse pas, vous obtenez la ligne et la colonne exactes, une explication claire et une correction suggérée plutôt qu’un volet vide. Pour une conversion à répéter, yq -o=json input.yaml fait le même travail depuis un terminal.

Cliquez sur Importer pour choisir un fichier .yaml ou .yml, ou glissez-le n’importe où sur cette page, puis cliquez sur Télécharger pour enregistrer le résultat en fichier .json. Le fichier est lu par votre navigateur et n’est jamais envoyé nulle part, ce qui compte pour une configuration contenant des noms d’hôte, des registres ou des identifiants. Depuis un shell, utilisez yq -o=json input.yaml > output.json, ou convertissez tout un répertoire avec : for f in *.yaml; do yq -o=json "$f" > "${f%.yaml}.json"; done

Oui, dans presque tous les cas. YAML 1.2 est défini comme un sur-ensemble de JSON, et tout document YAML construit avec des mappages, séquences, chaînes, nombres, booléens et nuls ordinaires a un équivalent JSON exact. Quatre choses ne survivent pas au voyage : les commentaires, car JSON n’a aucune syntaxe pour eux ; les ancres et alias, développés en leurs valeurs complètes puisque JSON ne sait pas exprimer une référence ; les clés de mappage qui ne sont pas des chaînes, comme des dates ou des structures imbriquées, que JSON n’autorise pas ; et les tags personnalisés comme !Ref ou !GetAtt, qui n’ont aucun sens hors de leur outil. Ce convertisseur signale chacun de ces cas au lieu de les ignorer en silence.

C’est l’inverse : le JSON est du YAML valide, mais le YAML n’est en général pas du JSON valide. La spécification YAML 1.2 définit le langage comme un sur-ensemble de JSON, donc tout document JSON peut être passé tel quel à un analyseur YAML 1.2 — vous pouvez coller du JSON dans le volet YAML ci-dessus et il sera analysé. Un document YAML n’est du JSON valide que par hasard, s’il est écrit dans le style de flux de JSON avec toutes les clés et chaînes entre guillemets et sans commentaires ; le YAML ordinaire basé sur l’indentation est rejeté par tout analyseur JSON. La garantie s’applique à YAML 1.2 — YAML 1.1, qu’implémentent PyYAML et les outils plus anciens, n’est pas un sur-ensemble strict de JSON.

JSON est un format d’échange strict pour les machines ; YAML est un format de configuration pour les humains capable d’exprimer les mêmes données. Concrètement : YAML tire sa structure de l’indentation tandis que JSON utilise accolades et crochets ; YAML accepte des commentaires avec # et JSON n’en a aucun ; YAML peut réutiliser des blocs via ancres, alias et clés de fusion tandis que JSON répète chaque valeur en entier ; YAML peut contenir plusieurs documents dans un fichier séparés par ---, là où JSON contient exactement une valeur ; et YAML laisse généralement les chaînes sans guillemets, ce qui est pratique jusqu’à ce que country: NO soit lu comme false. Comme YAML 1.2 est un sur-ensemble de JSON, tout ce que JSON peut exprimer, YAML le peut aussi.

Utilisez YAML quand un humain écrit et maintient le fichier, et JSON quand une machine l’écrit ou le lit. YAML est rentable pour la configuration relue en revue de code — manifestes Kubernetes, Docker Compose, workflows GitHub Actions, playbooks Ansible, spécifications OpenAPI — parce que les commentaires expliquent les valeurs et que les ancres limitent la répétition. JSON est rentable pour les corps de requêtes et de réponses d’API, les lignes de log, les jeux de tests et tout ce qui est généré ou stocké en volume : il s’analyse plus vite, chaque langage fournit un analyseur, il n’y a pas d’espaces significatifs à rater ni d’ambiguïté de version à débattre. Quand les deux arguments s’appliquent, la réponse habituelle est d’écrire en YAML et de convertir en JSON au moment du build — c’est à cela que sert le convertisseur en haut de cette page.

YAML est plus facile à lire et plus difficile à écrire correctement ; JSON est plus verbeux et bien plus prévisible. En lisibilité, YAML l’emporte nettement pour la configuration imbriquée : pas de crochets fermants, pas de guillemets autour de chaque clé, pas de virgules à mal placer, et des commentaires pour expliquer les valeurs peu évidentes — le même manifeste Kubernetes est environ 40 % plus court en YAML qu’en JSON. Côté usage, la tendance s’inverse. L’indentation est significative, donc une tabulation égarée ou une clé sœur mal alignée casse le document ; les valeurs sans guillemets peuvent changer de type en silence (yes, no, on, off, 022, 12:30) ; les clés en double et la scission entre YAML 1.1 et 1.2 produisent des fichiers qui s’analysent proprement tout en se comportant mal ; et les erreurs des analyseurs YAML sont notoirement vagues sur l’emplacement du vrai problème. JSON n’a aucun de ces modes de défaillance, d’où la position pragmatique : écrire du YAML et le valider ou le convertir avant qu’il ne parte en production.