どちらを使用するかを答える前に、少し背景を説明します。
編集：私はこの比較は実際にはJavaScriptを使用してブラウザでそれらを使用するという観点からであることに言及する必要があります。それはどちらのデータフォーマット has も使われるべき方法ではありません、そして私が言っていることが全く有効ではないように詳細を変更するたくさんの良いパーサーがあります。
JSONは、よりコンパクトで、（私の考えでは）より読みやすくなります - 転送時には、転送されるデータが少ないために「高速」になることがあります。
解析では、それはあなたのパーサーに依存します。コード（JSONでもXMLでも）を（マップのような）データ構造に変換するパーサーは、XMLの厳密な性質（ XMLスキーマ の恩恵を受けることができます。データ構造を明確にします） - しかしJSONでは項目の型（String/Number/Nested JSON Object）は構文的に推測できます。例えば：
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
実際、良いパーサはあなたのためにageをうまくタイプするかもしれません（他方で、あなたはそれを望まないかもしれません）。このデータにアクセスすると、上のJSONの例のように属性検索を行うのではなく、キーnameでマップ検索を行います。このようにXMLを形成するほうがより直感的です。
<person name="Danielle" age="12" />
しかし、データにアクセスするには、まだマップ検索を行う必要があります。
myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");
編集：オリジナル：
ほとんどのプログラミング言語（全部ではありません）では、このようなマップ検索は属性検索よりもコストがかかります（JSONを解析したときに上記で得たように）。
これは誤解を招く可能性があります。JavaScript（およびその他の動的言語）では、マップ検索とフィールド検索の間に 違いはありません があることを忘れないでください。実際のところ、フィールドルックアップ は 単なるマップルックアップです。
本当に価値のある比較が必要な場合は、それをベンチマークすることが最善です。データを使用する予定の状況でベンチマークを実行します。
私がタイピングをしているうちに、Felix Klingは、それぞれをいつ使うべきかという点でそれらを比較してかなり簡潔な答えをすでに出しているので、これ以上先に進みません。
高速はJSONまたはXMLの属性ではなく、それらを比較しても得られる結果ではありません。もしあれば、それはパーサーの属性か、あなたがデータを送信するときに使う帯域幅です。
JSONとXMLの長所と短所は次のとおりです（の始まり）。
JSON
Pro：
- 単純な構文で、XMLに比べて「マークアップ」オーバーヘッドが少なくなります。
- マークアップとしてのJavaScriptでは、JSオブジェクトリテラル表記のサブセットであり、JavaScriptと同じ基本データ型を使用しているため、簡単に使用できます。
- 説明およびデータ型と構造の検証のためのJSONスキーマ
- 深くネストされた構造内の情報を抽出するためのJsonPath
コン：
単純な構文、ほんの一握りの異なるデータ型のみがサポートされています。
コメントはサポートされていません。
XML
Pro：
- 一般化されたマークアップあらゆる目的のために「方言」を作成することは可能です
- データ型、構造検証用のXMLスキーマ 。新しいデータ型を作成することも可能にします
- XSLT さまざまな出力形式に変換
- XPath / 深くネストされた構造内の情報を抽出するためのXQuery
- 名前空間のサポートを内蔵
コン：
- JSONと比較すると比較的言葉遣いです（同じ量の情報に対してより多くのデータが得られます）。
だから最後にあなたはあなたが必要とするものを決める必要があります。明らかに両方のフォーマットはそれらの合法的なユースケースを持っています。ほとんどの場合はJavaScriptを使用する予定であれば、JSONを使用する必要があります。
長所と短所を追加してください。私はXMLの専門家ではありません;）
処理速度が唯一の関連事項ではないかもしれませんが、それが問題なので、ここにベンチマークのいくつかの数字があります： JSON対XML：冗長性に関するいくつかの難しい数字 。速度を上げるために、この単純なベンチマークでは、XMLはJSONに対して21％のオーバーヘッドを示しています。
記事で述べられているように、冗長性に関する重要な注意点は、最も一般的な不満です。これは、実際にはそれほど重要ではありません（XMLやJSONデータは通常人間によってではなくマシンによって処理されません）。速度を上げるには、圧縮するのにある程度の時間がかかります。
また、このベンチマークでは、大量のデータが処理され、一般的なWebアプリケーションでは90MBという大きなサイズのデータチャンクは送信されず、圧縮は有益ではない場合があります（十分に小さいデータチャンクの場合、圧縮チャンク）。圧縮されていないチャンクよりも大きくなります）ので、適用されません。
それでも、圧縮が含まれていない場合、特にWebSocket接続を介して送信される場合は、JSONのほうが明らかに簡潔であるため、JSONの方が重みが少なくなります。重要です。
送信後、データが消費され、これが全体の処理時間にカウントされます。十分に大きいデータまたは複雑なデータを送信する場合は、検証中のXMLパーサーによって自動的にチェックされるスキーマがないため、JSONデータをさらにチェックする必要があります。これらのチェックはJavaScriptで実行する必要がありますが、これは特に高速ということは知られていないため、このような場合にはXMLに対して追加のオーバーヘッドが生じる可能性があります。
とにかく、テストだけがあなたの特定のユースケースに対する答えを提供します（速度が本当に唯一の問題であり、標準でも安全でも完全性でもないなら…）。
更新1：言及する価値があるのは、EXI、つまりGzipを使用するよりも低コストで圧縮を提供し、圧縮XMLを解凍するのに必要な処理を節約するバイナリXML形式です。 EXIはXMLに対するもので、BSONはJSONに対するものです。ここでは、空間と時間の両面での効率性について、簡単に概説します。 EXI：最後のバイナリ標準ですか？ 。
アップデート2：効率性、メモリおよびCPU使用量の低さもW3Cによって実施されたバイナリXMLパフォーマンスレポートも存在します。これはXML分野にも問題です： 効率的なXML交換評価 。
更新2015-03-01
HTTPオーバーヘッドが問題として提起されたので、この文脈で注目に値する：IANAは、HTTPのためのaaContent Codingとして、EXIエンコーディング（上記の効率的なバイナリXML）を登録した。プロトコル（compress、deflate、およびgzipと共に）。これはつまり、EXIは他のHTTPクライアントの中でもブラウザによって理解されることが期待できるオプションであることを意味します。 ハイパーテキスト転送プロトコルパラメータ（iana.org） を参照してください。
私はデジタルバザールで この記事を見つけました 本当に面白いです。 Normからの引用を引用する：
JSONプロについて
受け渡したいものがアトミック値、リスト、またはアトミック値のハッシュだけである場合、JSONにはXMLの多くの利点があります。インターネット上で簡単に使用でき、さまざまなアプリケーションをサポートし、JSONを処理するプログラムを作成するのは簡単です。オプション機能はほとんどなく、人間が判読でき、適度に明確で、デザインは形式的で簡潔、JSON文書は簡単に作成でき、Unicodeを使用しています。 ...
XMLの専門家について
XMLは、豊富な非構造化データを非常にうまく処理します。 XMLの死が喜んでWeb APIデザイナーの幹部によって祝われたとしても、私はXMLの将来についてまったく心配していません。
そして、私は「私はあなたにそう言った！」を押し込むのに抵抗することはできません。私の机の向こう側にトークン。私たちがより豊富なAPIを開発するよう求められたときにJSONの人々が何をするのか楽しみにしています。あまり構造化されていないデータを交換したい場合は、それをJSONに組み込む必要がありますか。 JSON用のスキーマ言語についての言及がときどき見られますが、他の言語も続くでしょうか。 ...
私は個人的にNormに同意します。私は、XMLへの攻撃の大部分はWeb開発者からのものであり、実際には統合開発者からのものではないと思います。しかし、それは私の意見です！ ;）
XML（拡張マークアップ言語）はXHRとしてよく使用されます。これは標準の放送言語であり、どのプログラミング言語でも使用でき、サーバー側とクライアント側の両方でサポートされているため、最も柔軟なソリューションです。特定のグループが他の部分に影響を与えることなくプログラムの一部を開発できるように、XMLをより多くの部分に分けることができます。 XMLフォーマットは、XML DTDまたはXMLスキーマ（XSL）によって決定することもでき、テストすることもできます。
JSONはJavaScriptアプリケーションとして可能なフォーマットとして普及しつつあるデータ交換フォーマットです。基本的にこれはオブジェクト表記法の配列です。 JSONは非常に単純な構文を持っているので簡単に習得できます。また、JavaScriptはeval関数を使ったJSONの解析もサポートしています。一方、eval関数はマイナスになります。たとえば、プログラムはJSONの解析が非常に遅くなる可能性があり、セキュリティ上の理由でevalは非常に危険になる可能性があります。これはJSONが良くないことを意味するのではなく、もっと慎重にならなければなりません。
私の提案は、ゲームのようにデータ交換が少ないアプリケーションにはJSONを使うべきだということです。あなたが本当にデータ処理を気にする必要はないので、これは非常に単純で速いです。
XMLは、ショッピングサイトなどの大規模Webサイトに最適です。 XMLはより安全で明確にすることができます。基本的なデータ構造とスキーマを作成して、修正を簡単にテストし、それを簡単に部分に分割することができます。
速度とセキュリティの観点からXMLを使用することをお勧めしますが、軽量なものにはJSONを使用してください。
JSONに関する重要なことは、セキュリティ上の理由からデータ転送を暗号化しておくことです。 JSONがXMLよりはるかに速いことは間違いありません。私はXMLが100msかかるのを見ましたが、JSONは60msしかかかりませんでした。 JSONデータは操作が簡単です。