JSON vs XML : différences et lequel choisir

JSON et XML structurent tous deux des données, mais pas pour les mêmes usages. Définitions, exemple comparé, différences concrètes et grille de choix pour votre API, votre site ou vos factures électroniques.

JSON et XML servent tous les deux à structurer et échanger des données sous forme de texte lisible. Pour une API web ou une application JavaScript, JSON est aujourd’hui le choix par défaut : plus léger, plus simple à lire et lu nativement par les navigateurs. XML reste le meilleur outil quand il faut valider strictement des documents, mêler texte et données ou respecter un standard existant, comme les sitemaps, le SVG ou les factures électroniques. Il n’y a donc pas de « meilleur » format dans l’absolu, mais un format adapté à chaque usage.

On reprend ici ce que sont JSON et XML, leurs vraies différences (syntaxe, types, validation, sécurité, performances), un exemple côte à côte, puis une grille simple pour choisir selon votre projet.

Qu’est-ce que le JSON ?
Qu’est-ce que le XML ?
À quoi ressemblent les mêmes données en JSON et en XML ?
Quelles sont les différences entre JSON et XML ?
Qu’ont-ils en commun ?
JSON ou XML : lequel choisir pour votre projet ?
Quelles erreurs éviter ?
Questions fréquentes
Sources

Qu’est-ce que le JSON ?

JSON signifie JavaScript Object Notation. C’est un format texte d’échange de données, popularisé au début des années 2000 par le programmeur américain Douglas Crockford. Comme l’explique le site de référence json.org, il repose sur un sous-ensemble de la syntaxe de JavaScript (ECMA-262, 3e édition de 1999), mais il est indépendant de tout langage : PHP, Python, Java, C#, Go ou Swift savent tous le lire et l’écrire.

Il est normalisé deux fois : par Ecma International sous le nom ECMA-404 (1re édition en octobre 2013, 2e édition en décembre 2017) et par l’IETF dans la RFC 8259 (décembre 2017), qui impose l’encodage UTF-8 pour les échanges entre systèmes.

Un document JSON se construit avec seulement deux structures :

l’objet : une collection de paires clé/valeur entre accolades, par exemple {"nom": "Dupont"} ;
le tableau : une liste ordonnée de valeurs entre crochets, par exemple ["rouge", "vert"].

Les valeurs possibles sont limitées et connues à l’avance : chaîne de caractères, nombre, objet, tableau, true, false et null. C’est cette simplicité qui explique son succès : en JavaScript, une seule ligne (JSON.parse()) transforme le texte reçu en objet utilisable, et JSON.stringify() fait l’inverse.

Pourquoi utiliser le JSON ?

JSON s’est imposé avec les applications web dynamiques : au lieu de recharger toute la page, le navigateur interroge une API et reçoit juste les données utiles. Le format est devenu le standard de fait des API REST, des applications mobiles, des fichiers de configuration (package.json, composer.json) et des bases NoSQL orientées documents. Google recommande aussi le JSON-LD pour les données structurées qui alimentent les résultats enrichis.

Ses limites sont tout aussi nettes : pas de commentaires autorisés, pas de type date natif (on passe par une chaîne au format ISO 8601), pas de validation intégrée et une syntaxe stricte (guillemets doubles obligatoires, aucune virgule finale). JSON.parse() lève une erreur au moindre écart.

Qu’est-ce que le XML ?

XML signifie Extensible Markup Language. C’est un langage de balisage publié par le W3C : la 1re édition de la recommandation XML 1.0 date du 10 février 1998, la version en vigueur est la 5e édition du 26 novembre 2008. Il dérive de SGML, en plus simple, et vise à être utilisable directement sur Internet par une grande variété d’applications.

« Extensible » veut dire que vous inventez vos propres balises : <commande>, <client>, <article>. XML ne dit rien de l’affichage, il décrit la structure et le sens des données sous forme d’arbre. Ce n’est pas un langage de programmation : il ne calcule rien, il stocke et organise.

Autour de XML s’est construit tout un écosystème : XSD (XML Schema) pour valider un document, XPath pour y chercher une information, XSLT pour le transformer (en HTML, en PDF, en un autre XML), et les espaces de noms pour mélanger plusieurs vocabulaires sans conflit. Les spécifications du W3C précisent d’ailleurs que la concision « a une importance minimale » : XML privilégie la clarté et la rigueur sur la légèreté.

À quoi ressemblent les mêmes données en JSON et en XML ?

Prenons une commande simple avec un client et deux articles. En JSON :

{
  "commande": {
    "numero": 1042,
    "client": "Marie Martin",
    "payee": true,
    "articles": [
      { "ref": "TS-01", "quantite": 2, "prix": 19.9 },
      { "ref": "CA-07", "quantite": 1, "prix": 12.5 }
    ]
  }
}

La même chose en XML :

<?xml version="1.0" encoding="UTF-8"?>
<!-- Commande issue de la boutique en ligne -->
<commande numero="1042" payee="true">
  <client>Marie Martin</client>
  <articles>
    <article ref="TS-01"><quantite>2</quantite><prix>19.9</prix></article>
    <article ref="CA-07"><quantite>1</quantite><prix>12.5</prix></article>
  </articles>
</commande>

Trois choses sautent aux yeux. JSON est plus court, car il n’a pas de balise fermante. JSON distingue nativement nombre, booléen et texte, alors qu’en XML tout est texte tant qu’un schéma ne dit pas le contraire. XML, lui, accepte un commentaire et offre le choix entre attribut (ref="TS-01") et élément enfant, ce qui donne plus de liberté mais aussi plus de décisions à prendre.

Quelles sont les différences entre JSON et XML ?

Critère	JSON	XML
Nature	Format de données	Langage de balisage
Structure	Objets (clé/valeur) et tableaux	Arbre d’éléments et d’attributs
Types	Chaîne, nombre, booléen, null, objet, tableau	Texte, types précisés par un schéma XSD
Commentaires	Non	Oui
Espaces de noms	Non	Oui
Validation	JSON Schema (outil externe)	DTD ou XSD, très répandus
Taille	Plus compacte	Plus verbeuse
Lecture en JavaScript	`JSON.parse()` natif	Analyseur XML (DOMParser, par exemple)
Contenu mixte (texte + balises)	Mal adapté	Conçu pour
Usages typiques	API REST, apps mobiles, configuration, JSON-LD	Sitemaps, flux RSS, SVG, bureautique, factures électroniques, SOAP

Syntaxe et lisibilité

JSON a une syntaxe minimale, facile à lire pour un développeur et rapide à écrire. XML est plus bavard, mais chaque valeur est étiquetée par sa balise, ce qui rend un document long plus « auto-descriptif » pour une personne qui ne connaît pas le code qui l’a produit.

Validation et schémas

C’est l’atout historique de XML. Un document peut pointer vers son schéma (XSD), qui fixe les champs obligatoires, leur ordre et leur type. Deux bénéfices : l’auteur sait exactement ce qu’il doit remplir, et l’application qui reçoit le fichier peut le rejeter s’il manque une balise. Pour une fiche véhicule définie par un schéma voiture.xsd, par exemple, on sait d’avance que marque, modèle et immatriculation doivent être présents.

JSON dispose aujourd’hui de JSON Schema, dont la version actuelle est la 2020-12. Il fait le même travail, mais il reste un outil à ajouter, alors que la validation fait partie de la culture XML depuis le départ.

Types de données et contenus binaires

JSON connaît les nombres et les booléens, XML non (sans schéma). En revanche, aucun des deux ne transporte d’image « en direct » : dans les deux cas, un fichier binaire doit être encodé en texte (Base64) ou, mieux, remplacé par une URL. L’idée, répandue, selon laquelle XML gérerait nativement images et graphiques est donc inexacte.

Sécurité

Côté XML, le risque le plus connu est l’attaque XXE (XML External Entity) : un analyseur mal configuré qui accepte les entités externes peut lire des fichiers du serveur ou appeler des adresses internes. L’OWASP recommande de désactiver complètement les DTD et les entités externes lorsqu’on traite du XML non maîtrisé.

Côté JSON, le danger historique venait de JSONP, une astuce pour contourner la règle de même origine qui exécutait du code distant. Elle est aujourd’hui remplacée par CORS. Il faut surtout ne jamais évaluer du JSON avec eval(), toujours passer par JSON.parse(), et valider les données reçues comme n’importe quelle entrée utilisateur. Notre article sur la sécurité des applications web détaille ces réflexes.

Performances

À contenu égal, un fichier JSON est généralement plus petit et plus rapide à analyser, surtout dans un navigateur. Avec la compression HTTP (gzip, Brotli), l’écart de poids se réduit fortement. Pour la très grande majorité des sites et applications, ce n’est pas la performance qui doit trancher, mais l’usage.

Qu’ont-ils en commun ?

Le même objectif : stocker et transporter des données structurées entre systèmes.
Du texte lisible par un humain comme par une machine, avec prise en charge d’Unicode.
Une structure hiérarchique : des valeurs imbriquées dans d’autres valeurs.
Une indépendance vis-à-vis des langages : tous les langages courants ont des bibliothèques pour les deux.
Un transport par HTTP : les deux se récupèrent avec fetch() ou l’ancien XMLHttpRequest, dont le nom rappelle d’ailleurs qu’il a d’abord été pensé pour XML.

JSON ou XML : lequel choisir pour votre projet ?

La comparaison n’est pas tout à fait équitable : JSON est un format de données simple, XML une famille d’outils pour décrire des documents. La bonne question est donc « quel est mon usage ? ».

Choisissez JSON si…

vous créez ou consommez une API pour un site, une application mobile ou un front JavaScript ;
vous échangez des données entre vos outils (CRM, boutique, outils marketing) via des webhooks ;
vous ajoutez des données structurées schema.org à vos pages ;
vous voulez un format rapide à mettre en place et facile à déboguer.

Choisissez XML si…

un standard vous l’impose : sitemap (le protocole sitemaps.org est en XML, 50 000 URL et 50 Mo maximum par fichier), flux RSS ou Atom, SVG, services SOAP anciens, formats bureautiques ;
vous traitez des factures électroniques : les formats UBL et CII sont en XML, et Factur-X associe un PDF lisible à un fichier XML structuré. Depuis le 1er septembre 2026, toutes les entreprises françaises doivent pouvoir recevoir des factures électroniques, et l’obligation d’émission s’étendra aux PME et TPE au plus tard le 1er septembre 2027 ;
vous avez besoin d’une validation stricte, de documents mêlant texte et balises, ou de transformations XSLT ;
votre ERP ou votre partenaire logistique ne parle que XML (fréquent dans l’industrie et la banque).

Dans la pratique, beaucoup de projets utilisent les deux : une boutique en ligne expose une API JSON pour son application et génère en parallèle un sitemap XML et un flux produits XML pour Google Merchant Center. Si vous devez faire dialoguer plusieurs outils qui ne parlent pas le même format, c’est exactement le travail de notre offre d’intégration et d’automatisation, avec un budget qui dépend des outils à connecter (voir nos tarifs indicatifs).

Quelles erreurs éviter ?

Convertir mécaniquement du XML en JSON : attributs, espaces de noms et ordre des éléments n’ont pas d’équivalent direct. Définissez la structure JSON cible au lieu de laisser un convertisseur automatique décider.
Ajouter des commentaires ou des virgules finales dans un JSON : le fichier devient invalide et l’analyse échoue.
Stocker des dates dans des formats libres : utilisez l’ISO 8601 (2026-09-26T10:00:00Z) dans les deux formats.
Laisser un analyseur XML en configuration par défaut sur des fichiers venus de l’extérieur, sans désactiver les entités externes.
Se passer de validation sous prétexte que JSON n’en impose pas : un JSON Schema évite bien des bugs silencieux entre deux applications.

Questions fréquentes

JSON va-t-il remplacer XML ?

Non. JSON a remplacé XML pour la plupart des API web, mais XML reste la base de standards très actifs : sitemaps, SVG, formats bureautiques, factures électroniques. Les deux vont coexister longtemps.

Qui a inventé le JSON ?

Douglas Crockford l’a spécifié et popularisé au début des années 2000. Il a ensuite été normalisé par Ecma International (ECMA-404, 2013) puis par l’IETF (RFC 8259, 2017).

JSON est-il un langage de programmation ?

Non, c’est un format de données. Il ne contient ni instruction ni logique, seulement des valeurs. Il en va de même pour XML, qui est un langage de balisage.

Peut-on mettre des commentaires dans un fichier JSON ?

Pas dans du JSON standard. Certains outils acceptent des variantes (JSONC, JSON5) pour leurs fichiers de configuration, mais elles ne doivent pas être envoyées à une API qui attend du JSON strict.

Quel format pour les données structurées SEO ?

Google recommande en général le JSON-LD, plus simple à mettre en place et à maintenir que les microdonnées insérées dans le HTML.

JSON vs XML : différences, exemples et lequel choisir