更快不是JSON或XML的属性，也不是两者之间比较产生的结果。如果有，则是解析器的属性或传输数据的带宽。

以下是JSON和XML优缺点的列表(开头部分):

JSON

Pro:

简单的语法，与XML相比，这将导致更少的“标记”开销。 易于与JavaScript一起使用，因为标记是JS对象文字表示法的一个子集，并且具有与JavaScript相同的基本数据类型。 用于描述、数据类型和结构验证的JSON模式 用于从深度嵌套结构中提取信息的JsonPath

Con:

语法简单，只支持少数几种不同的数据类型。 不支持评论。

XML

Pro:

通用标记;为任何目的创建“方言”都是可能的 用于数据类型、结构验证的XML模式。也可以创建新的数据类型 XSLT用于转换成不同的输出格式 用于从深度嵌套结构中提取信息的XPath/XQuery 内置了对名称空间的支持

Con:

与JSON相比相对冗长(导致相同数量的信息有更多数据)。

所以最后你必须决定你需要什么。显然，这两种格式都有其合法的用例。如果你主要使用JavaScript，那么你应该使用JSON。

请随意添加优点和缺点。我不是XML专家;)

在回答什么时候用哪个之前，先了解一下背景:

edit:我应该提到的是，这种比较实际上是从在JavaScript浏览器中使用它们的角度进行的。这不是任何一种数据格式必须使用的方式，而且有很多好的解析器会改变细节，使我所说的不太有效。

JSON既更紧凑，(在我看来)可读性更强——在传输方面，它可以“更快”，因为传输的数据更少。

在解析中，它取决于您的解析器。解析器将代码(无论是JSON还是XML)转换为数据结构(如地图)可能受益于XML的严格性质(XML模式很好地消除了数据结构的歧义)-然而在JSON中，可以从语法上推断项目的类型(字符串/数字/嵌套JSON对象)，例如:

myJSON = {"age" : 12,
          "name" : "Danielle"}

解析器不需要足够智能才能意识到12代表一个数字(Danielle和其他字符串一样是一个字符串)。所以在javascript中我们可以做到:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

在XML中，我们必须做如下的事情:

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(顺便说一句，这说明XML更加冗长;对数据传输的关注)。为了使用这些数据，我们将通过解析器运行它，然后我们必须调用如下命令:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

实际上，一个好的解析器很可能会为您键入年龄(另一方面，您也可能不希望它这样做)。当我们访问这些数据时，我们不是像上面的JSON示例那样进行属性查找，而是对键名进行映射查找。这样的XML格式可能更直观:

<person name="Danielle" age="12" />

但我们仍然需要进行地图查找来访问我们的数据:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

编辑:原:

在大多数编程语言中(不是所有语言)，这样的映射查找比属性查找(就像我们上面解析JSON时得到的那样)代价更大。

这是一种误导:请记住，在JavaScript(和其他动态语言)中，映射查找和字段查找之间没有区别。事实上，字段查找就是映射查找。

如果您想要一个真正有价值的比较，最好是对其进行基准测试——在您计划使用数据的上下文中进行基准测试。

就在我打字的时候，Felix Kling已经给出了一个相当简洁的答案，就何时使用它们进行了比较，所以我就不再继续了。

XML(可扩展标记语言)通常使用XHR，因为这是一种标准的广播语言，任何编程语言都可以使用它，并且同时支持服务器端和客户端，因此这是最灵活的解决方案。XML可以被分离成更多的部分，这样指定的小组就可以开发程序的一部分，而不影响其他部分。XML格式也可以由XML DTD或XML模式(XSL)确定，并且可以进行测试。

The JSON a data-exchange format which is getting more popular as the JavaScript applications possible format. Basically this is an object notation array. JSON has a very simple syntax so can be easily learned. And also the JavaScript support parsing JSON with the eval function. On the other hand, the eval function has got negatives. For example, the program can be very slow parsing JSON and because of security the eval can be very risky. This not mean that the JSON is not good, just we have to be more careful.

我的建议是，您应该将JSON用于具有少量数据交换的应用程序，如游戏。因为您不必真正关心数据处理，所以这非常简单和快速。

XML最适合大型网站，比如购物网站之类的。XML可以更安全、更清晰。您可以创建基本的数据结构和模式，以轻松地测试更正并轻松地将其分离为部分。

我建议您使用XML，因为它的速度和安全性，但JSON是轻量级的东西。

关于JSON的重要事情是出于安全原因保持数据传输的加密。毫无疑问，JSON比XML快得多。我曾见过XML需要100毫秒，而JSON只需要60毫秒。JSON数据很容易操作。

处理速度可能不是唯一相关的问题，但是，这就是问题所在，下面是基准测试中的一些数字:JSON vs. XML:关于冗长性的一些硬性数字。为了提高速度，在这个简单的基准测试中，XML的开销比JSON高21%。

关于冗长有一个重要的注意事项，正如文章所说，这是最常见的抱怨:这在实践中并没有太大的相关性(XML和JSON数据通常都不是由人类处理的，而是由机器处理的)，即使出于速度的考虑，它也需要一些合理的更多时间来压缩。

此外，在这个基准测试中，处理了大量的数据，而典型的web应用程序不会传输这种大小的数据块，大到90MB，压缩可能没有好处(对于足够小的数据块，压缩后的块将比未压缩的块大)，因此不适用。

不过，如果不涉及压缩，显然更简洁的JSON在传输通道中的权重会更小，特别是通过WebSocket连接传输时，在这种情况下，没有经典的HTTP开销可能会使JSON的优势更加显著。

在传输之后，数据将被消耗，这将在整个处理时间中计算。如果要传输足够大或复杂的数据，由于缺乏由验证XML解析器自动检查的模式，可能需要对JSON数据进行更多检查;这些检查必须在JavaScript中执行，而JavaScript的速度并不是特别快，因此在这种情况下，它可能会在XML上产生额外的开销。

无论如何，只有测试才能为您的特定用例提供答案(如果速度真的是唯一的问题，而不是标准、安全或完整性……)

更新1:值得一提的是，EXI是二进制XML格式，它提供的压缩成本比使用Gzip低，并且节省了解压压缩XML所需的处理。EXI之于XML，就像BSON之于JSON。这里有一个快速的概述，并参考了空间和时间的效率:EXI:最后的二进制标准?

更新2:还有一个二进制XML性能报告，由W3C进行，作为效率和低内存和CPU占用，也是XML领域的一个问题:高效XML交换评估。

更新2015-03-01

在这个上下文中值得注意的是，由于HTTP开销被作为一个问题提出:IANA已经注册了EXI编码(上面提到的高效二进制XML)，作为HTTP协议的内容编码(与compress、deflate和gzip一起)。这意味着EXI是一个可以被其他HTTP客户端的浏览器理解的选项。参见超文本传输协议参数(iana.org)。

我发现这篇文章在数字集市真的很有趣。引用Norm的名言:

关于JSON的优点:

如果你想传递的只是原子值或列表或哈希 原子值，JSON具有XML的许多优点:它是 可直接在互联网上使用，支持多种 应用程序，很容易编写程序来处理JSON，它有很少 可选功能，它是人类易读和合理清晰的设计 是正式和简洁的，JSON文档易于创建，并且它使用 Unicode……

关于XML的优点:

XML deals remarkably well with the full richness of unstructured data. I’m not worried about the future of XML at all even if its death is gleefully celebrated by a cadre of web API designers. And I can’t resist tucking an "I told you so!" token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow? ...

我个人同意Norm的观点。我认为大多数针对XML的攻击都来自典型应用程序的Web开发人员，而不是真正的集成开发人员。但这只是我的观点!；）