Quelle est la différence entre XML et JSON ?
Ce qui distingue les deux formats de données et ce que change la conversion
Un service vous réclame un fichier XML, alors que vous n'avez qu'un export .json tiré d'une application. Ou l'inverse : votre comptable vous a envoyé une facture électronique au format XML et le logiciel dans lequel vous voulez la charger attend du JSON. Cet article répond à la seule question qui compte à ce moment-là : qu'est-ce qui sépare exactement ces deux formats, et quelle partie de cette différence vous concerne ?
Réponse courte : tous deux véhiculent les données en texte brut et peuvent contenir les mêmes informations. Ils diffèrent par la manière de baliser les données et par le format que le programme d'en face sait lire. Autrement dit, la plupart du temps ce n'est pas vous qui choisissez, c'est le système destinataire. À vous de reconnaître ce que vous avez entre les mains et de savoir ce qui change à la conversion.
Un même enregistrement, deux formats : voir la différence
Le moyen le plus rapide de saisir la différence est de placer les mêmes informations côte à côte. Dans le schéma ci-dessous, le numéro d'une commande, le client et le montant sont écrits à la main, d'abord en XML, puis en JSON. Le contenu est identique ; seul l'emballage change.
En XML, chaque valeur se trouve dans une balise : elle s'ouvre avec <client> et se ferme avec </client>. Comme chaque nom est écrit deux fois, le même enregistrement est plus long en XML. En JSON, le nom n'apparaît qu'une fois, suivi de deux-points et de la valeur, et les accolades marquent le début et la fin de l'enregistrement. Le nombre de caractères sous le schéma chiffre cet écart.
Remarquez aussi le montant : dans les deux formats il s'écrit 249.90 avec un point, même si votre tableur affiche 249,90. Les formats de données utilisent le point comme séparateur décimal, même sur un ordinateur réglé en français.
Quel est le format de votre fichier ? Regardez le premier caractère
L'extension ne dit pas toujours la vérité. Certains logiciels livrent du XML sous le nom .txt ou .dat, certains services téléchargent du JSON sans aucune extension. Le seul test fiable consiste à regarder dedans, et aucun programme particulier n'est nécessaire. Lancez le Bloc-notes (TextEdit sur Mac) et choisissez le fichier par le menu Fichier > Ouvrir du programme. Sous Windows, réglez en bas à droite de cette fenêtre le type sur « Tous les fichiers », sinon un fichier qui ne se termine pas par .txt n'apparaît même pas. Dans le texte affiché, ignorez les espaces éventuels et regardez le premier signe visible :
- S'il s'agit de <, surtout si le fichier commence par <?xml : c'est du XML
- S'il s'agit de { ou de [ : c'est du JSON
- Si les lignes sont du texte simple coupé par des points-virgules ou des virgules, ce n'est ni l'un ni l'autre ; c'est très probablement un fichier CSV
- Si vous ne voyez que des symboles illisibles, le fichier n'est pas du texte (une archive compressée, par exemple) et aucun des deux formats n'est en cause
Les différences dans un seul tableau
Voici ce que le schéma signifie concrètement. Prêtez une attention particulière à la troisième ligne : c'est la différence qui surprend le plus lors d'une conversion, et elle revient dans les sections suivantes.
| Sujet | XML | JSON |
|---|---|---|
| Écriture | Balises ouvrantes et fermantes : <nom>…</nom> | Accolades et paires "nom" : valeur |
| Informations annexes | Peuvent être accrochées à la balise : <commande num="1042"> | Pas d'emplacement prévu ; chaque information est un champ |
| Nombre ou texte | Dans le fichier, toute valeur est du texte ; un fichier de schéma séparé en donne le type | Nombres sans guillemets, texte entre guillemets ; true, false et null sont des types à part |
| Listes | La même balise répétée à la suite | Éléments entre crochets : [ … ] |
| Commentaires | Possibles entre <!-- et --> | Non prévus |
| Niveau extérieur | Une seule balise extérieure obligatoire | Aucune règle de ce type |
| Longueur | Plus long, les noms étant répétés | Plus court pour les mêmes données |
Pourquoi un système exige du XML et un autre du JSON ?
C'est le programme qui lira le fichier qui fixe le format : il attend celui pour lequel il a été conçu. XML est le plus ancien des deux, et une grande partie des échanges de documents administratifs, des logiciels de comptabilité et des liaisons entre entreprises repose sur lui. Dans de nombreux pays, la facture électronique est un document XML ; c'est pourquoi une facture reçue d'un fournisseur ou d'un comptable arrive si souvent en .xml.
JSON, de son côté, est devenu la langue commune des services web et des applications mobiles. Quand vous appuyez sur « télécharger mes données » dans une application, ou quand deux programmes dialoguent derrière un site, c'est généralement du JSON qui circule. Les flux RSS des sites d'information et les plans de site remis aux moteurs de recherche (sitemap.xml) restent, eux, en XML.
En pratique, la question « lequel est le meilleur ? » se pose rarement pour vous. Si l'autre partie attend du XML, même un JSON parfait sera refusé. Quand votre format ne correspond pas à celui demandé, il faut convertir ; si le choix vous revient vraiment, regardez l'exemple de fichier dans l'aide du programme destinataire et tenez-vous-en à ce format.
Que change la conversion, et perd-on quelque chose ?
Les deux formats portent les mêmes informations, mais pas dans le même moule : convertir, c'est donc adapter et non copier. Les convertisseurs de ce site adaptent vos données de la façon suivante, sans le cacher :
- XML vers JSON : les informations accrochées à une balise sont conservées sous forme de champ dont le nom commence par @. Le numéro de <commande num="1042"> apparaît en JSON comme "@num" : "1042"
- XML vers JSON : toutes les valeurs arrivent sous forme de texte entre guillemets. XML ne distingue pas nombre et texte dans le fichier, donc 249.90 devient "249.90" ; le programme qui fera les calculs devra le reconvertir en nombre
- XML vers JSON : les commentaires entre <!-- --> et la ligne <?xml ?> du début ne sont pas repris, faute d'équivalent en JSON
- JSON vers XML : aucune information n'est accrochée aux balises, chaque clé devient un élément distinct ; si le système destinataire attend le numéro sur la balise elle-même, il faudra retoucher le résultat à la main
- JSON vers XML : la distinction entre nombre et texte disparaît, les deux deviennent du texte simple dans une balise
Ne convertissez pas un document officiel pour le renvoyer
Ces adaptations ont une conséquence : si vous convertissez un fichier de XML en JSON puis de nouveau en XML, vous ne retrouvez pas le document de départ caractère pour caractère. Les noms d'éléments, l'ordre et la place des informations annexes peuvent bouger. Pour des données courantes, c'est sans importance ; pour un document officiel, si.
Dans un document signé électroniquement, comme une facture électronique, la signature dépend de chaque caractère du fichier ; il suffit qu'une espace change pour qu'elle ne soit plus vérifiable. La raison légitime de convertir un tel XML est de le lire : voir les lignes de la facture, reporter les montants dans un autre tableau. Gardez l'original intact, envoyez l'original s'il doit partir quelque part et réservez la copie convertie à votre propre usage.
Avant de convertir, vérifiez que le fichier est sain
Un convertisseur ne fonctionne qu'avec un document qui respecte ses propres règles. En XML, une seule balise non fermée ou une valeur sans guillemets rend tout le fichier illisible. Si votre XML tient sur une seule ligne ou si un service répond « fichier non valide », collez-le d'abord dans l'outil « Formater et valider un XML » : le texte est mis en retrait et, s'il y a une erreur, sa ligne et sa colonne vous sont indiquées. Pour le JSON, le « Formateur et validateur JSON » fait le même travail.
Ce contrôle a une limite qu'il faut connaître. Il vérifie que le document est correctement écrit, pas qu'il contient tous les champs exigés par le système destinataire. Les champs obligatoires sont fixés par le fichier de schéma (XSD) publié par l'organisme. « Bien formé » signifie donc que le fichier est lisible ; cela ne garantit pas qu'il sera accepté.
Questions fréquentes
XML ou JSON : lequel est le meilleur ?
Il n'y a pas de gagnant absolu. Le bon format est celui que demande le système destinataire. Si le choix vous appartient et que les données circulent entre applications ou services web, JSON est plus court et plus répandu ; pour les échanges formels de documents entre organismes, XML reste la norme.
Perd-on des informations en convertissant du XML en JSON ?
Les valeurs restent, seule leur forme change : les informations accrochées aux balises deviennent des champs commençant par @, et les nombres arrivent sous forme de texte entre guillemets. Seuls les commentaires placés entre <!-- et --> disparaissent, car JSON n'en prévoit pas.
Comment lire confortablement une facture au format XML ?
Pour voir les lignes de la facture sous forme de tableau, l'outil « Convertir un XML en Excel (XLSX) » transforme les enregistrements répétés en lignes et les champs en colonnes. Pour simplement parcourir le contenu, l'outil « Formater et valider un XML » met le texte en retrait et le rend lisible. Dans les deux cas, le fichier source reste intact.
Puis-je donner mon fichier JSON à un système qui demande du XML ?
Oui, après l'avoir converti avec l'outil « Convertir un JSON en XML ». Avant l'envoi, comparez le résultat avec le fichier d'exemple du système : la balise la plus extérieure et le nom des éléments de liste doivent correspondre à ce qui est attendu. L'outil vous laisse saisir vous-même le nom de la balise extérieure.
HTML et XML, est-ce la même chose ?
Ils se ressemblent, tous deux utilisant des balises entre chevrons. Mais HTML possède un jeu de balises fixe qui décrit l'apparence d'une page à l'écran ; en XML, c'est celui qui prépare les données qui choisit le nom des balises, et l'objectif est la donnée elle-même, pas son affichage.
Dernière mise à jour : 12 octobre 2026