Convertisseur JSON → XML, gratuit

JSON et XML, deux formats, deux ères

XML (Extensible Markup Language) a été standardisé par le W3C en tant que recommandation le 10 février 1998, la spec W3C XML 1.0, éditée par Tim Bray, Jean Paoli et C.M. Sperberg-McQueen. XML est issu de SGML (le plus ancien « Standard Generalised Markup Language », ISO 8879:1986) en supprimant les fonctionnalités les plus complexes et en produisant quelque chose que le web pouvait réalistement utiliser. Pendant à peu près la première décennie du XXIᵉ siècle, XML était le format présumé pour tout échange de données structurées, services web SOAP, flux RSS (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), formats Open XML de Microsoft Office (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), layouts XML Android, fichiers de propriétés Java, configuration dans presque chaque framework serveur. Les forces de XML sont les espaces de noms, les attributs, le contenu mixte (texte et éléments enfants entrelacés) et un riche écosystème de schémas (DTD, XML Schema 1.1, Relax NG). Sa faiblesse est la verbosité, chaque valeur porte une balise ouvrante et fermante.

JSON (JavaScript Object Notation) a été spécifié par Douglas Crockford en 2001, le site json.org et son essai original « JSON: The Fat-Free Alternative to XML ». JSON est intentionnellement un sous-ensemble de la syntaxe littérale d'objet JavaScript : objets, tableaux, chaînes, nombres, true/false/null. Standardisé en tant que RFC 4627 en juillet 2006, raffiné en RFC 7159 (mars 2014) et RFC 8259 (décembre 2017, standard STD 90 actuel, également publié par l'ECMA en tant qu'ECMA-404). La conquête par JSON des API web aux dépens de XML s'est faite à peu près en 2008-2014, le calendrier correspond à l'essor des applications monopage et de l'ère des API mobiles. Aujourd'hui presque chaque API publique se documente en JSON ; XML survit principalement dans l'intégration d'entreprise, les formats de documents, les fichiers de configuration et les formats de flux. Les deux formats restent en usage actif parce qu'ils encodent bien des choses différentes : JSON convient aux données structurées avec des types simples et une forme prévisible ; XML convient aux documents avec contenu mixte, attributs, espaces de noms et schémas rigoureux.

Quand vous avez vraiment besoin de convertir JSON en XML

• Appeler un service web SOAP depuis un client uniquement-JSON. SOAP est XML par conception (l'enveloppe SOAP, la description de service WSDL, les schémas XSD). Si vous avez des données sous forme JSON et devez construire un corps de requête SOAP, JSON-vers-XML est le pont. Courant dans l'intégration d'entreprise quand des microservices modernes doivent parler à des endpoints SOAP legacy (banque, gouvernement, assurance, systèmes d'échange de santé).
• Génération de documents Office Open XML à partir de données JSON. Les formats .docx, .xlsx et .pptx sont des archives ZIP de fichiers XML. Pour générer ou modifier programmatiquement des documents Office à partir de données soutenues par JSON, la conversion JSON-vers-XML se passe à la frontière entre la couche de données de votre application et la bibliothèque de génération de documents.
• Production d'un flux RSS ou Atom à partir de contenu JSON. Blogs, sites d'actualités et plates-formes de podcast émettent des flux RSS/Atom pour la syndication. Si votre CMS stocke les articles en JSON, l'étape de génération de flux convertit les entrées JSON dans le format XML que l'écosystème de lecteurs de flux attend.
• Génération de fichiers de configuration XML pour applications legacy. Beaucoup d'applications d'entreprise plus anciennes (serveurs d'application Java, fichiers de configuration .NET, contexte d'application Spring XML) consomment leur configuration en XML. Le tooling moderne d'infrastructure-en-tant-que-code travaille typiquement en YAML ou JSON, donc une conversion JSON-vers-XML s'insère dans le pipeline de déploiement.
• Alimenter une transformation XSLT. XSLT (XSL Transformations, spécification de Michael Kay, recommandation W3C) est le langage standard de transformation XML et consomme de l'entrée XML. Si vos données partent en JSON et que votre moteur de reporting est basé sur XSLT, la conversion se passe à la frontière d'entrée.
• Génération de fichiers de ressources Android. Les strings.xml, colors.xml, dimens.xml et fichiers de layout d'Android sont du XML. Les pipelines de localisation qui stockent les chaînes en JSON pour la facilité d'édition convertissent en XML au moment du build.

Le mapping de conversion, où l'information survit et où elle se perd

JSON et XML ont des primitives structurelles différentes, donc toute conversion doit faire des choix. Le mapping JSON-vers-XML standard que la plupart des convertisseurs (celui-ci inclus) suivent :

• Les objets JSON deviennent des éléments XML. Chaque clé devient un élément enfant avec la clé comme nom de balise. {"name": "Alice"} devient <name>Alice</name>.
• Les tableaux JSON deviennent des éléments enfants répétés. {"items": [1, 2, 3]} devient trois enfants <item>1</item><item>2</item><item>3</item> à l'intérieur du wrapper <items>. (Différents convertisseurs utilisent différentes conventions pour le nom de l'élément de tableau ; certains utilisent le nom du parent au singulier, d'autres utilisent un <item> fixe.)
• Chaînes, nombres, booléens deviennent le contenu textuel de l'élément. L'information de type n'est pas préservée, XML traite tout texte comme données de caractères, donc un aller-retour XML → parse → resérialise vers JSON émettrait les nombres comme chaînes entre guillemets sauf si le consommateur applique une inférence de type.
• null devient un élément vide auto-fermant. {"middle_name": null} devient <middle_name/>. Certains convertisseurs utilisent xsi:nil="true" à la place.
• L'élément racine enveloppe tout. JSON autorise un tableau ou scalaire de premier niveau ; XML exige exactement un élément racine. Le wrapper <root> (configurable ici) est la solution conventionnelle.

Information perdue dans la conversion : la distinction de JSON entre nombres et chaînes, la distinction de JSON entre true/false et chaînes « true »/« false », la distinction tableau vs objet de JSON (quand un tableau devient des éléments répétés vous ne pouvez pas dire à partir du seul XML si la source avait un tableau d'un élément ou une valeur unique). Information potentiellement gagnée mais non utilisée par les convertisseurs simples : les attributs XML (un objet JSON pourrait mapper les clés à des attributs plutôt qu'à des éléments enfants), les espaces de noms XML (JSON n'a rien d'équivalent), les sections CDATA (pour intégrer du texte avec des caractères spéciaux XML). Pour une conversion JSON-vers-XML aller-retour-sûre qui préserve l'information de type, la convention BadgerFish ou la convention Parker encodent les types JSON comme attributs XML namespaced, cet outil produit la forme plus simple et plus lisible plutôt que la forme aller-retour-sûre.

Les contraintes de nom de balise XML que les clés JSON n'ont pas

Les clés d'objet JSON sont des chaînes arbitraires, n'importe quel Unicode est autorisé. Les noms d'éléments XML sont bien plus restreints : ils doivent commencer par une lettre ou un underscore (pas un chiffre, un tiret ni un point), peuvent contenir lettres, chiffres, tirets, underscores et points (pas d'espaces, pas la plupart des ponctuations), sont sensibles à la casse, et ne peuvent pas commencer par le préfixe réservé xml dans aucune combinaison de casse. Les clés JSON avec espaces ("first name": "Alice"), les clés commençant par des chiffres ("3rd_choice"), ou les clés avec caractères spéciaux ("@type", "$value") ne peuvent pas être utilisées comme noms d'éléments XML directement. La plupart des convertisseurs (celui-ci inclus) déforment silencieusement les caractères invalides, remplacent les espaces par des underscores, préfixent les clés commençant par des chiffres avec un underscore, suppriment la plupart des ponctuations. Soyez conscient de cela en aller-retour : un document JSON avec clés non-XML-sûres ne fera pas un aller-retour identiquement à travers XML.

Là où XML règne encore en 2026

XML n'est pas en repli en 2026, il s'est juste installé dans des niches spécifiques. Formats de documents : Office Open XML (Microsoft Office), OpenDocument (LibreOffice), ebooks EPUB, SVG (recommandation W3C 4 septembre 2001), MathML, XHTML. Configuration : serveurs d'application Java, contextes Spring XML, POM Maven, ressources XML Android, fichiers app.config et web.config .NET. Flux : RSS 2.0, Atom 1.0 (RFC 4287), flux de podcasts (les extensions RSS d'iTunes). Échange en santé et gouvernement : HL7 v3, FHIR (qui propose maintenant JSON comme alternative mais la forme XML reste massivement utilisée), DocBook, NewsML, ISO 20022 bancaire. Organismes de standards : presque chaque exemple de spécification IETF et W3C utilise XML. La verbosité de XML est une fonctionnalité dans ces domaines : il est auto-descriptif, la validation contre un schéma est bien établie, et les transformations XSLT entre dialectes XML sont une boîte à outils mature. Le format n'ira nulle part ; la conversion JSON-vers-XML est le pont entre l'outillage de données moderne et ces systèmes XML-natifs établis.

Confidentialité : conversion uniquement dans le navigateur

Le JSON collé dans un convertisseur contient souvent de vraies données de production, réponses d'API avec identifiants utilisateur, IDs internes d'entité qui révèlent la taxonomie métier, valeurs de configuration qui incluent des URLs d'endpoints et des feature flags, tokens, contenus brouillon non encore publiés. Les convertisseurs côté serveur prennent une copie de chaque entrée dans leurs logs. Ce convertisseur parse votre JSON avec le JSON.parse() intégré au navigateur, parcourt l'arbre d'objets résultant en JavaScript et émet le XML sous forme de chaîne, le tout dans votre onglet de navigateur. Vérifiez dans l'onglet Réseau des DevTools en cliquant sur Convert (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement et le convertisseur fonctionne toujours. Sûr pour les réponses d'API de production, la configuration interne, le contenu brouillon ou tout JSON que vous ne voudriez pas voir copié sur le disque dur d'un inconnu.

Questions fréquentes

Comment les tableaux JSON sont-ils convertis ?

Chaque élément du tableau devient un élément enfant séparé. {"colors": ["red", "blue"]} devient <colors><item>red</item><item>blue</item></colors>. Le nom d'élément conventionnel pour les entrées de tableau anonymes est <item>. Si votre consommateur en aval attend une convention différente (par ex. forme singulière du nom du parent comme <color>), vous devrez post-traiter le XML ou utiliser un convertisseur différent qui prend en charge le nommage personnalisé d'éléments de tableau.

Cela fonctionne-t-il avec de gros fichiers JSON ?

Oui, comme tout tourne dans votre navigateur, le plafond pratique est la mémoire disponible de votre appareil. Des dizaines de milliers de lignes de JSON se convertissent en bien moins d'une seconde sur un ordinateur portable moderne. De très grosses entrées (plusieurs Mo) peuvent figer brièvement l'onglet pendant que le parser parcourt l'arbre. Pour la conversion en lot de grands ensembles de données, un script utilisant un convertisseur côté serveur (xml2js en Node, dicttoxml en Python) est plus approprié.

Mon JSON est-il téléversé sur un serveur ?

Non. La conversion s'exécute entièrement dans votre navigateur, le JSON collé ne quitte jamais votre appareil. Vérifiez dans l'onglet Réseau des DevTools en cliquant sur Convert (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement. Sûr pour les réponses d'API de production, la configuration interne, ou toute donnée que vous ne voudriez pas partager à l'extérieur.

Puis-je faire en sorte que certaines clés JSON deviennent des attributs XML plutôt que des éléments enfants ?

Ce convertisseur émet toutes les clés JSON comme éléments enfants, pas comme attributs. La convention que certains convertisseurs utilisent (clés préfixées par @ deviennent attributs ("@id": 5 → id="5" sur le parent)) est la convention BadgerFish. Si votre consommateur en aval exige certaines valeurs comme attributs, vous aurez besoin d'un convertisseur personnalisé qui comprend la convention, ou d'éditer à la main le XML résultant.

Que se passe-t-il pour les clés JSON contenant des espaces ou des caractères XML invalides ?

Les noms d'éléments XML ont des règles plus strictes que les clés JSON : ils doivent commencer par une lettre ou un underscore, ne peuvent pas contenir d'espaces et interdisent la plupart des ponctuations. Les clés avec caractères invalides sont assainies, les espaces deviennent underscores, les chiffres en tête reçoivent un préfixe underscore, les caractères spéciaux sont supprimés. Cela signifie qu'un aller-retour JSON → XML → JSON peut ne pas produire les noms de clés originaux exactement. Si vos données ont des clés inhabituelles, inspectez la sortie pour vous assurer que la déformation n'a rien cassé d'important.

Outils associés