JSON出现在足够多的不同角色中，值得将它们分开：格式在任何地方都是相同的，但每个用例实际需要的东西不同，将一个与另一个混淆是尴尬决策的常见来源（向机器生成的API负载添加注释，或期望NDJSON日志管道作为单个JSON文档解析）。
REST API负载
按体积最常见的用例。请求体和响应体每个都是一个JSON文档，Content-Type: application/json，由一方生成，另一方消费，中间没有人类阅读。这里不需要注释或手动编辑便利；需要的是一种无歧义的语法，所有语言都以相同方式解析，这是JSON的实际优势。REST负载也是JSON Schema Validator存在的形式：根据API应该履行的合同检查响应，准确查看哪个字段违反了它以及为什么，在该bug到达假设字段在那里的生产代码之前。
应用程序配置
package.json、tsconfig.json、composer.json，以及数十个工具配置。这是JSON缺乏注释实际上有代价的用例：没有解释的设置，因为格式没有地方放置。一些工具用// comment键绕过这一点，没有人以编程方式阅读，其他工具切换到YAML或JSON超集（JSON5、JSONC）添加回注释。参见JSON vs YAML了解完整的权衡；简短版本是手工编辑的配置文件通常受益于YAML的注释，而完全由工具生成和消费的配置作为普通JSON没问题。
NoSQL和文档数据库
MongoDB将文档存储为BSON，这是JSON数据模型的超集二进制格式，当你查询时返回JSON（或类似JSON的shell语法）。CouchDB和大多数文档存储直接接受和返回JSON。这里的吸引力是结构性的：文档数据库的全部主张是将数据存储在你的应用程序已经使用的大致形状中，而不是首先将其规范化为行和外键，JSON的对象和数组模型足够接近大多数语言的原生类型，转换几乎是免费的。
日志行和流数据：NDJSON
单个JSON文档流式传输效果不佳：解析器通常需要整个文档才能产生值，因为文档只有在最终闭合大括号到达时才有效。Newline Delimited JSON (NDJSON)通过使每行成为自己的完整、独立的JSON值来解决这个问题，因此日志管道、Kafka主题或大型导出可以逐行处理而无需将整个文件保持在内存中。JSON to NDJSON Converter将JSON数组转换为此每行一个记录的格式并反向，对流中有一行格式错误的情况进行恢复，而不是因一个坏记录而使整个文件失败。
浏览器存储
localStorage和sessionStorage只存储字符串；任何结构化内容都作为JSON.stringify(value)进入，作为JSON.parse(stored)出来。这也是数字精度问题JSON数据类型详解覆盖的地方成为真正bug而不是好奇心的地方：通过浏览器自己的JSON.parse在localStorage中往返大整数ID可能悄悄更改值，这正是此站点自己的工具构建来避免和报告而不是重现的失败模式。
用你自己的数据尝试
上面提到的每个工具完全在你的浏览器中运行：粘贴到JSON Formatter、NDJSON converter或Schema Validator中的内容永远不会上传到任何地方，这对本页面讨论的真实API响应和配置文件最为重要。