Convertisseur JSON ↔ YAML
JSONConvertit entre JSON et YAML 1.2 avec validation en direct et localisation des erreurs (ligne/colonne).
Les URL distantes ne sont pas récupérées ; collez votre JSON directement.
Sur cette page
Qu’est-ce qu’un convertisseur YAML / JSON ?#
YAML et JSON sont deux façons d’écrire le même type de données — tables de hachage imbriquées, listes, chaînes, nombres, booléens et null. Le JSON est strict et truffé de ponctuation (toutes les chaînes entre guillemets doubles, des crochets partout) ; le YAML troque ces guillemets et accolades contre de l’indentation et des tirets, ce qui le rend assez lisible pour que des humains le rédigent à la main pour des fichiers de configuration, des pipelines de CI et des manifestes de conteneurs.
Vous avez sans cesse besoin de passer de l’un à l’autre parce que les outils préfèrent des formats différents. Un chart Kubernetes se rédige en YAML mais l’API parle JSON. Une configuration de CI est en YAML ; le linter auquel vous voulez la soumettre attend du JSON. Un collègue colle un bloc YAML dans une conversation ; votre script veut JSON.parse. Faire cela à la main — réindenter, ajouter des guillemets, remplacer des tirets par des crochets — est précisément le genre de travail minutieux qui introduit une virgule parasite ou un espace mal aligné, après quoi plus rien ne s’analyse.
Cette page convertit dans les deux sens, dans votre navigateur. YAML vers JSON quand vous avez besoin de la rigueur adaptée aux machines ; JSON vers YAML quand vous voulez un fichier de configuration qu’un humain puisse relire. Elle analyse avec le schéma core de YAML 1.2 (pas d’instanciation d’objet risquée), localise les erreurs à une ligne et colonne exactes, et refuse de replier les longues lignes afin que la sortie reste adaptée aux diffs.
Mode d’emploi#
- Choisissez un sens avec le commutateur à deux boutons en haut à gauche de la barre d’outils :
- YAML → JSON (par défaut) : collez du YAML à gauche, obtenez du JSON strict à droite.
- JSON → YAML : collez du JSON à gauche, obtenez du YAML indenté à droite.
- Choisissez l’Indentation — 2 ou 4 espaces. Cela contrôle la profondeur d’imbrication de la sortie des deux côtés.
- Cliquez sur Exemple pour charger un court exemple si vous souhaitez observer le comportement avant de coller vos propres données, ou sur Effacer pour vider les deux panneaux.
- Le panneau de droite se met à jour au fil de la conversion. La barre d’état située en dessous affiche l’une de trois choses : une ligne de succès avec la taille en octets de la sortie, une indication d’entrée vide, ou une erreur d’analyse avec une ligne et colonne à partir de 1 pointant le jeton fautif exact.
- Cliquez sur Copier dans l’en-tête de sortie pour récupérer le résultat.
La conversion s’exécute dès que l’entrée s’analyse. Il n’y a pas de bouton Générer à cliquer — corrigez l’entrée et la sortie se rafraîchit.
Principales fonctionnalités#
- Bidirectionnel, une paire de panneaux. La même disposition entrée/sortie gère les deux sens ; le commutateur décide quel analyseur s’exécute.
- Schéma core YAML 1.2.
null,true/false, les entiers, les flottants et les chaînes entre guillemets sont résolus exactement comme le ferait un analyseur conforme à la norme — pas par une heuristique permissive. - Repliage de lignes désactivé. Les longues lignes de sortie ne sont jamais coupées ni éludées, donc un diff contre un fichier versionné ne montre que des changements réels.
- Localisation exacte des erreurs. Une indentation mal alignée ou un
:parasite est signalé parligne:colonne, et non par un générique « impossible d’analyser ». - Protégé contre la profondeur. Une entrée profondément imbriquée (le classique dépliement en cascade « billion-laughs » du YAML) est plafonnée, donc un fichier hostile ou accidentellement récursif ne peut pas figer l’onglet.
- Local uniquement. Votre configuration ne quitte jamais la page — il n’y a aucun backend vers lequel l’envoyer. Au-delà d’un mégaoctet, l’analyse lourde est confiée à un worker en arrière-plan afin que l’interface reste réactive.
Exemple détaillé#
Une tâche réelle courante : une configuration de service rédigée en YAML doit entrer dans le corps d’une requête JSON. Collez ceci dans le panneau de gauche avec YAML → JSON et indentation 2 :
name: api-gateway
port: 8080
replicas: 3
targets:
- host: example.com
port: 443
- host: cdn.example.com
port: 8443
features:
retries: true
timeout_ms: 2500
Le panneau de droite produit du JSON strict, prêt à être analysé :
{
"name": "api-gateway",
"port": 8080,
"replicas": 3,
"targets": [
{
"host": "example.com",
"port": 443
},
{
"host": "cdn.example.com",
"port": 8443
}
],
"features": {
"retries": true,
"timeout_ms": 2500
}
}
Notez que les valeurs YAML sans guillemets 8080, true et 3 sont devenues respectivement un nombre, un booléen et un nombre JSON — le schéma core les a typés, vous n’avez pas eu à le faire. Inversez le sens (JSON → YAML) et collez le JSON en retour : vous obtenez la même structure imbriquée réindentée avec des tirets pour les éléments de liste, ce qui est la forme que vous versionneriez dans un dépôt de configuration.
FAQ#
Mes commentaires YAML sont-ils conservés à l’aller-retour ?#
Non. Le JSON n’a aucune syntaxe de commentaire, donc tout # commentaire de votre YAML est lu puis abandonné en chemin vers le JSON — il n’y a simplement nulle part où le mettre. Les commentaires sont tolérés en entrée (ils ne provoquent jamais d’erreur), mais ils ne peuvent pas survivre à la traversée. Si les commentaires comptent, gardez le YAML comme source de vérité et générez le JSON à partir de lui à chaque fois.
Gère-t-il le YAML multi-documents (fichiers séparés par ---) ?#
Il traite le flux de documents et renvoie le document de tête. La plupart des fichiers de configuration et de manifestes sont mono-document, donc c’est rarement un problème ; si vous avez un flux multi-documents, séparez-le sur les --- et convertissez chaque partie.
YAML ou JSON pour mon fichier de configuration — que choisir ?#
Utilisez le YAML quand un humain le rédige à la main et que vous souhaitez une lisibilité proche du commentaire, avec des ancres et une imbrication par indentation. Utilisez le JSON quand une machine le produit et qu’un analyseur le consomme, ou quand la rigueur compte (le JSON a exactement une seule manière légale d’écrire chaque valeur, donc aucune ambiguïté à déboguer). Cet outil existe pour que vous n’ayez pas à vous limiter à un seul.
L’erreur indique « ligne 4, colonne 5 » mais cette ligne semble correcte. Qu’est-ce qui cloche ?#
Presque toujours l’indentation. Le YAML décide la structure à partir des espaces de tête, donc un enfant décalé d’un espace trop à gauche ou trop à droite — ou un mélange de tabulations et d’espaces — remonte sous forme d’erreur sur la ligne après le vrai coupable, parce que l’analyseur ne remarque l’incohérence qu’en lisant le jeton suivant. Vérifiez d’abord l’indentation de la ligne située au-dessus de la ligne signalée.