XML 比 JSON 早近十年，在 2000 年代一直是 Web 服务（SOAP、RSS、大多数企业集成）的默认选择。JSON 在能力上并没有胜过它，XML 可以表示 JSON 所能表示的 任何东西甚至更多; 它在重量和直接性上获胜，用于在 服务器和客户端之间移动数据的特定工作。
相同的数据，两种方式
<user>
<name>Ada Lovelace</name>
<age>36</age>
<active>true</active>
<skills>
<skill>mathematics</skill>
<skill>writing</skill>
</skills>
</user>{
"user": {
"name": "Ada Lovelace",
"age": 36,
"active": true,
"skills": ["mathematics", "writing"]
}
}XML 版本需要每个开始标签对应一个结束标签，以及一个重复的
<skill> 元素来表示列表，因为 XML 没有原生的数组
语法; 具有多个 <skill> 子级的 <skills> 元素可以同样
容易地是一个 <skill> 子级，只有模式或约定告诉
阅读器是哪一个。JSON 的 [ ] 用两个字符明确地说“列表”。
XML 仍然获胜的地方
内容旁的属性。 <price currency="USD">42.00</price>
将元数据附加到值上，无需发明包装对象。JSON 没有
属性概念; 相同的数据变成 {"price": {"value": 42.00, "currency": "USD"}} 或像 @currency 键这样的约定，两者都比
XML 对此形状的原生语法更不直接。
混合内容。 带有内联标记的文字段落，<p>Some <b>bold</b> text</p>，是 XML 的原生优势，这就是为什么文档格式
（DocBook、大多数出版管道、SVG）仍然使用它。JSON 完全无法
交织文本和标记; 在 JSON 中表示丰富的文档通常意味着
类型化节点的树，这比 XML 标记已经免费提供给你的
需要编写和阅读更多代码。
命名空间和严格模式。 XML Schema (XSD) 和命名空间允许 大型组织在一个文档中混合来自不同来源的词汇表， 而不会名称冲突，拥有存在超过二十年的工具。 JSON Schema 存在并且确实做实际工作（JSON Schema Generator 从真实文档推断一个）， 但它比 XSD 在大型企业系统中更年轻且部署更不广泛。
JSON 获胜的地方，也就是大多数 API
重量。 没有结束标签意味着相同数据的传输和解析更少， 在深度嵌套的文档上通常有很大的余量。
直接映射到程序自己的数据结构。 JavaScript 中的 JSON.parse，
或几乎每种其他语言中的等效一行代码，将 JSON 文档转换为
该语言的原生对象和数组类型，无需中间模型。XML 需要 DOM，
或模式生成的类，位于文本和程序实际使用的
数据之间。
没有隐式类型问题。 每个 XML 值都是文本，直到某些外部
内容（模式、约定）说不是; <age>36</age> 是包含
“36” 的字符串，除非被告知是数字。JSON 的 number、boolean
和 null 类型在语法本身中是显式的，因此没有需要
配置或猜测的内容。
实际中
今天新的 REST API 几乎无一例外地默认为 JSON。XML 在 其自身优势具有决定性的地方持续存在: 旧企业系统中的 SOAP 服务、 RSS 和 Atom 提要、SVG 和其他标记原生格式，以及 属性或混合内容是数据的实际形状 而非尴尬拟合的任何地方。
相互转换
JSON to XML Converter 双向运行，
具有命名空间前缀和给定值成为 XML 属性还是
子元素的控制，因为该选择没有单一正确答案，
并且取决于消费输出的内容。它使用浏览器自己的
DOMParser 读取 XML 而不是手写解析器，每个值
在进入时都作为字符串返回，工具会说明这一点而不是
静默猜测 XML 本身不携带的类型。