可读性
JSON和 XML的可读性可谓不相上下，一边是简易的语法，一边是规范的标签形式，很难分出胜负。
XML天生有很好的扩展性，JSON当然也有，没有什么是XML可以扩展而JSON却不能扩展的。不过JSON在Javascript主场作战，可以存储Javascript复合对象，有着xml不可比拟的优势。
XML有丰富的 编码工具，比如Dom4j、JDom等，JSON也有提供的工具。无工具的情况下，相信熟练的开发人员一样能很快的写出想要的xml文档和JSON 字符串，不过，xml文档要多很多结构上的字符。
XML的解析方式有两种：
一是通过文档模型解析，也就是通过父标签索引出一组标记。例如：xmlData.getElementsByTagName("tagName")，但是这样是要在预先知道文档结构的情况下使用，无法进行通用的封装。
另外一种方法是遍历节点（document 以及 childNodes）。这个可以通过 递归来实现，不过解析出来的数据仍旧是形式各异，往往也不能满足预先的要求。
凡是这样可扩展的结构数据解析起来一定都很困难。
JSON也同样如此。如果预先知道JSON结构的情况下，使用JSON进行数据传递简直是太美妙了，可以写出很实用美观可读性强的代码。如果你是纯粹的前台开发人员，一定会非常喜欢JSON。但是如果你是一个应用开发人员，就不是那么喜欢了，毕竟xml才是真正的结构化 标记语言，用于进行数据传递。
而如果不知道JSON的结构而去解析JSON的话，那简直是噩梦。费时费力不说，代码也会变得冗余拖沓，得到的结果也不尽人意。但是这样也不影响众多前台开发人员选择JSON。因为json.js中的toJSONString()就可以看到JSON的字符串结构。当然不是使用这个字符串，这样仍旧是噩梦。常用JSON的人看到这个字符串之后，就对JSON的结构很明了了，就更容易的操作JSON。
以上是在Javascript中仅对于数据传递的xml与JSON的解析。在Javascript地盘内，JSON毕竟是主场作战，其优势当然要远远优越于xml。如果JSON中存储Javascript复合对象，而且不知道其结构的话，我相信很多程序员也一样是哭着解析JSON的。
除了上述之外，JSON和 XML还有另外一个很大的区别在于有效数据率。JSON作为数据包格式传输的时候具有更高的效率，这是因为JSON不像XML那样需要有严格的闭合标签，这就让有效数据量与总数据包比大大提升，从而减少同等数据流量的情况下，网络的传输压力 [2] 。
虽然YAML是参考JSON，XML和SDL等语言，不过跟这些语言比起来，YAML仍有自己的特色。
JSON的语法是YAML1.2版的子集，同时非常接近YAML1.0与1.1版的子集，因此大部分的JSON文件都可以被YAML的剖析器剖析。这是因为JSON的语法结构和YAML的内置格式相同。虽然大范围的分层也可以使用类似JSON的内置格式，不过YAML标准并不建议这样使用，除非这样编写能让文件可读性增加。YAML的许多扩展在JSON是找不到的，如：进阶资料形态、关系锚点、字串不需要双引号、映射资料形态会储存键值的顺序。
XML和SDL标签概念，在YAML中是找不到的。对于数据结构序列（尽管这是有争议的），标签属性的特色就是可以将资料及复杂资料附加资讯分离，并将各种原生数据结构（如：杂凑表、阵列）用同一种语言表示。YAML则以资料的可扩展性作为替代。（包括为了模拟物件的类别型态）在YAML本身的规范中，并没有类似XML的语言定义文件纲要（language-defined document schema descriptors）──例如验证自己本身的结构是否正确的文件。不过，YAML纲要描述语言（YAML schema descriptor language）是存在的。另外还有YAXML──用XML描述YAML的结构──可以让XML Schema与XSLT转换程式应用在YAML之上。况且，在一般使用的情况下，YAML丰富的定义型态之语法已经提供了足够的方式来辨认YAML文件是否正确。
由于YAML的运作主要依赖大纲式的缩排来决定结构，这有效解决了界定符冲突（Delimiter collision）的问题。YAML的资料形态不依赖引号之特点，使的YAML文件可以利用区块，轻易的插入各种其他类型文件，如：XML、SDL、JSON，甚至插入另一篇YAML。
相反的，要将YAML置入XML或SDL中时，需要将所有空白字符和位势符号（potential sigils，如：<,>和&）转换成实体语法；要将YAML置入JSON中，需要用引号框住，并转换内部的所有引号。
跟SDL、JSON等，每个子结点只能有单一一个父节点的阶层式模型不同，YAML提供了一个简单的关系体制，可以从树状结构的其他地方，重复相同的资料，而不必显示那些冗余的结构。这点和XML中的IDRef类似，YAML剖析器在将YAML转换成物件时，会自动将那些参考资料的结构展开，所以程式在使用时并不会查觉到哪些资料是解码自这种结构。XML则不会将这种结构展开。这种表示法可以增加程式的可读性，并且，在那种“大部分参数维持和上次相同，只有少数改变”的设定档及通讯协定中，可以减少数据输入错误。一个例子是：“送货地点”和“购买地点”在发票的纪录中几乎都是相同的资料。
YAML是“行导向的”，因此，就算想由现有程序的混乱输出，转换成YAML格式，并保留大部分的原始文件之外观，也非常简单。因为他不需要平衡封闭的标签、括号及引号，可以从很简单的利用程式，从报表产生YAML。同样，空格分隔可让使用行导向的命令如：grep、Awk、perl、ruby，和Python，来应急性的过滤YAML文件时更加方便。
特别是与标记语言不同的，连续的YAML区块导向往往是格式良好的YAML文件本身。这使得很容易撰写那种“在开始提取的具体记录之前，不需要‘读取全部文件内容’”的解析器（通常需要平衡起始和关闭标签、寻找引号和跳脱字符）。当处理一个单一静态的，整个存在内存中的数据结构将很大，或为提取一个项目来重建的整个结构，代价相当昂贵的记录档，这种特性是相当方便的。
值得讨论的是，尽管它的缩排方式似乎复杂化了深度很大的巢状层次，YAML将缩排视为一个单一的空白，这可能会取得比其他标记语言更好的压缩比。此外，极深的缩排可以完全避免的是：
-
使用“内置格式”（即简称类JSON格式）而无缩排；
-
使用关联锚点展开阶层以形成一个摊平的格式，使得YAML解析器能透明地重组成完整的数据结构。
YAML是纯粹用来表达资料的语言，所以内部不会存 代码注入的可执行命令。这代表剖析器会相当（至少）安全的解析文件，而不用担心潜在与执行命令相关的安全漏洞。举例来说，JSON是JavaScript的子集，使用JavaScript本身的剖析器是相当诱人的，不过也造成许多代码注入的漏洞。虽然在所有资料序列语言中，安全解析本质上是可能的，但可执行性却正是这样一个恶名昭彰的缺陷；而YAML缺乏相关的命令语言，可能相对安全。
XML和YAML规范提供非常不同的逻辑模型来进行资料结点的展现、处理及储存。