En quoi consiste cet outil ?
XML et JSON sont tous deux des formats de données arborescents, mais ils apparaissent dans des contextes différents : les API d'entreprise historiques, les services SOAP, les flux RSS/Atom et de nombreux formats de configuration utilisent encore XML, tandis que les API REST modernes et le code JavaScript utilisent presque exclusivement JSON. Cet outil traduit entre les deux afin que vous n'ayez pas à écrire l'un ou l'autre à la main lorsque vous intégrez des systèmes anciens et nouveaux.
La conversion s'appuie directement sur l'API DOMParser du navigateur pour lire le XML, et suit la structure définie par la spécification W3C XML 1.0 pour le générer, de sorte que le XML produit est bien formé et que le XML accepté est analysé de la même manière qu'un navigateur ou toute bibliothèque XML conforme aux standards le ferait.
Comme XML possède des concepts que JSON n'a pas (attributs, contenu mixte texte/éléments, un unique élément racine obligatoire) et que JSON possède des concepts que XML n'a pas (tableaux natifs, booléens, nombres), l'outil utilise une convention documentée et largement répandue : un attribut XML `nom="valeur"` devient la clé JSON `"@_nom": "valeur"`, le contenu textuel d'un élément devient soit sa valeur de chaîne directe (quand il n'a ni enfants ni attributs), soit une clé `"#text"` aux côtés des attributs éventuels, et des éléments frères répétés portant la même balise deviennent un tableau JSON.
Pourquoi l'utiliser ?
- Bidirectionnel : convertissez JSON en XML ou XML en JSON depuis le même écran.
- Gère correctement l'imbrication : les objets JSON imbriqués deviennent des éléments XML imbriqués et inversement, quelle que soit la profondeur.
- Les tableaux sont mappés vers des éléments répétés : un tableau JSON sous une clé devient autant d'éléments XML frères portant la même balise, et les balises XML répétées reviennent sous forme de tableau JSON.
- Les attributs XML sont préservés grâce à la convention `@_nomAttribut`, afin que les données d'attribut ne soient jamais perdues silencieusement.
- Copiez dans le presse-papiers ou téléchargez au format .json ou .xml.
- 100 % côté client : rien de ce que vous collez n'est envoyé où que ce soit.
Mode d'emploi
- Choisissez un sens : « XML → JSON » ou « JSON → XML ».
- Collez vos données dans le champ de saisie.
- Cliquez sur « Convertir ».
- Vérifiez le résultat, puis copiez-le ou cliquez sur « Télécharger » pour enregistrer un fichier.
Exemple
Entrée
{"user":{"name":"Alice","age":30}}Résultat
<?xml version="1.0" encoding="UTF-8"?>
<user>
<name>Alice</name>
<age>30</age>
</user>L'unique clé de premier niveau du JSON (« user ») devient l'élément racine du XML ; si le JSON comporte plusieurs clés de premier niveau, l'outil enveloppe le tout dans un élément <root>, car XML exige exactement un seul élément racine.
Conseils pratiques
- Migrer une configuration XML héritée (comme le fichier de paramètres d'une ancienne application) vers un système moderne basé sur JSON : collez le XML, convertissez, puis ajustez les noms de champs si nécessaire.
- Tester un point de terminaison SOAP ou XML-RPC depuis JavaScript : convertissez ici votre corps de requête JSON en XML avant de l'envoyer, ou reconvertissez une réponse XML en JSON pour l'inspecter facilement.
- Si votre JSON utilise des tableaux pour des données que XML représenterait par des éléments répétés, veillez d'abord à imbriquer le tableau sous une seule clé (par exemple {"items":{"item":[1,2,3]}}) plutôt qu'un tableau nu de premier niveau, car XML ne peut pas avoir plusieurs éléments racines.
Pourquoi la convention d'attribut @_ est importante
La partie la plus délicate de la conversion JSON/XML tient au fait que les éléments XML peuvent porter deux types de données à la fois, des attributs et du contenu enfant, alors qu'un simple objet JSON n'a que des clés et des valeurs. Sans convention pour les distinguer, un convertisseur naïf perdrait complètement les attributs ou les mélangerait avec les éléments enfants d'une façon impossible à reconvertir de manière fiable. La convention du préfixe `@_nom` (également utilisée par des bibliothèques largement adoptées dans l'écosystème JavaScript) résout ce problème en donnant aux attributs une forme de clé distincte et sans ambiguïté, si bien que `<product id="42">Widget</product>` se convertit proprement dans les deux sens en `{"product":{"@_id":"42","#text":"Widget"}}`, sans perdre l'id ni deviner incorrectement à quoi correspond chaque valeur.
Foire aux questions
Que se passe-t-il pour un JSON comportant plusieurs clés de premier niveau ?
XML exige un unique élément racine, donc si votre objet JSON comporte plusieurs clés de premier niveau (par exemple {"a":1,"b":2}), le résultat est enveloppé dans un élément <root> : <root><a>1</a><b>2</b></root>. Si votre JSON n'a qu'une seule clé de premier niveau, celle-ci devient directement le nom de l'élément racine.
Comment les attributs XML sont-ils représentés en JSON ?
Un attribut comme <user id="7"> devient la clé "@_id": "7" dans l'objet JSON obtenu. C'est une convention courante et documentée (utilisée par des bibliothèques comme fast-xml-parser) qui permet de distinguer clairement les attributs des éléments enfants.
Les éléments XML répétés deviennent-ils un tableau JSON ?
Oui. Si un élément possède plusieurs enfants portant la même balise, par exemple <items><item>1</item><item>2</item></items>, la conversion en JSON produit {"items":{"item":["1","2"]}}. Reconvertir ce JSON en XML reproduit les éléments <item> répétés.
Les nombres et les booléens sont-ils préservés lors de la conversion de XML en JSON ?
XML n'a aucune notion native de nombres ou de booléens : tout est du texte, donc le contenu textuel devient une chaîne JSON (par exemple "30" plutôt que 30). Si vous avez besoin de types numériques, vous devrez convertir ces champs par la suite.
Mes données sont-elles envoyées quelque part ?
Non. L'analyse et la conversion se déroulent entièrement en JavaScript dans votre navigateur, via l'API DOMParser intégrée : rien n'est envoyé à un serveur, ce qui rend l'outil sûr pour des fichiers de configuration privés ou des données internes d'API.