免费在线 JSON 格式化器和验证器

JSON 是什么，以及为什么它接管了网络

JSON（JavaScript Object Notation）是一种从 JavaScript 对象字面量语法派生而来的、基于文本的数据交换格式。它支持六种数据类型（对象、数组、字符串、数字、布尔值和 null）除此以外没有别的。Douglas Crockford 于 2001 年规范化了这个格式，作为对 XML 的一个有意为之的极简替代方案，他把这套设计发布在 json.org 上，明确目标是做出「XML 的瘦身替代品」。IETF 于 2006 年 7 月将 JSON 标准化为 RFC 4627，2014 年 3 月将其精炼为 RFC 7159，又在 2017 年 12 月再次精炼为 RFC 8259（即当前的 STD 90，正在生效的标准；同时也作为 ECMA-404 并行发布）。JSON 对网络数据面的接管大致发生在 2008 到 2014 年之间：随着单页应用和移动客户端的兴起，早期 API 所使用的冗长 XML 负载被 JSON 取代了。到 2026 年，几乎每一个公开的 REST API 都用 JSON 来给自己写文档；XML 在文档格式和企业集成里仍然存活，但 API 经济已经被 JSON 拿下。这个工具读取 JSON、按规范进行校验，并把它重新输出为格式化（缩进、换行）或最小化（去掉空白）的形式。

「Format JSON」到底在做什么

在规范层面，JSON 对空白不敏感，一个解析器读取 {"name":"Alice","age":30} 和读取多行缩进版本是完全等价的。看得见的差别纯粹是给人类读者看的。格式化（也叫「pretty-printing」或「美化」）会在嵌套层级之间插入缩进，把每个属性放到单独一行，并在键和值之间的冒号之后加上空格。最小化做的是反向操作：除字符串字面量内部之外，把每一个空白字节都剥掉。生产环境里的 HTTP 响应通常是最小化过的，用来节约带宽（CDN 边缘上的 gzip 和 Brotli 会处理剩下的压缩）；开发期间则是读格式化后的版本。标准的格式化约定有：每个缩进层级用 2 个空格（现代 Web 的默认值，Prettier 的默认值，JavaScript 生态的常态）、4 个空格（用于遵循 Python 风格约定的代码库）、或 1 个 Tab（用于偏好制表符缩进的项目）。JavaScript 中的 JSON.stringify() 接受一个整数或字符串作为第二个参数，正好用来控制这件事，JSON.stringify(data, null, 2) 产生的就是 2 空格缩进的输出。这个工具向你暴露的就是同样的三个选项。

JSON 很严格，那些把人绊住的规则

JSON 的语法以毫不通融出名。对象的键必须用双引号包起来（单引号不合法）。字符串值也必须使用双引号。不允许结尾逗号（也就是对象最后一个属性或数组最后一个元素之后不能有逗号）这是很多 JavaScript 开发者会感到意外的地方，因为 JS 本身是允许结尾逗号的。不允许注释（和 YAML 或 JavaScript 不同，JSON 没有任何注释语法。不存在 undefined 这个值）JSON 只有 null；试图把 JavaScript 的 undefined 序列化为 JSON 会让那个属性整个消失。数字必须是 JSON 十进制形式（不允许前导零（007 非法）、不允许十六进制（0x7F 非法）、不允许 Infinity 和 NaN。字符串必须是合法的 UTF-8）大多数解析器会容忍 UTF-16 代理对的问题，但规范要求格式良好的 Unicode。重复键在规范上技术上是合法的，但在大多数解析器中会产生未定义行为（通常是后一个值胜出）。有几个 JSON 变种放宽了这些规则：JSON5（Aseem Kishore，2012）允许结尾逗号、单引号、注释和其他工程学上的放宽；JSONC（被 VS Code 的 tsconfig.json 等使用）就是允许 C 风格行注释的 JSON；HJSON 则致力于人类友好，键的引号是可选的。这些都不是真正的 JSON，它们各自需要自己的解析器，而大多数生产工具按照 RFC 8259 期望的是严格 JSON。

格式化 JSON 在哪些场景下真正有用

• 读 API 响应。一个 REST 接口在生产环境里返回的是最小化的 JSON。要在调试时检查它，把它粘到这里，看着带缩进和键着色的结构，找到 bug。
• 读结构化日志行。现代日志栈（Datadog、Splunk、Elasticsearch、CloudWatch）每行日志会发出一个 JSON 对象，全部挤在一行里。要快速读懂一条复杂的日志条目，就在这里把它格式化一下。
• 审查配置文件。package.json、tsconfig.json、composer.json、AWS IAM 策略、Kubernetes 的 JSON 清单，格式一致的时候都更容易审查。「Sort Keys」选项会产生一个规范化的字母顺序，对比较两份配置文件时很有用。
• 比较两份 JSON 文档。两份都用一致的缩进和键排序格式化好，再用你喜欢的 diff 工具去比较结果。如果不先做规范化，那些语义上完全相同、只是空白或键顺序不同的 JSON 会产生噪声很大的 diff。
• 校验一份手写编辑过的 JSON 文件。粘进来，点 Validate，如果有语法错误，位置和消息会准确告诉你该看哪里。比把文件丢进一个最终在「unexpected token at line 47」处失败的构建里要快得多。
• 找到通往一个深层嵌套值的路径。打开 Tree 视图，点击你关心的那个值，看它的 JSONPath 表达式，这对编写 jq 查询、测试中的 JSONPath 断言，或者在代码里访问那个字段都很有用。
• 部署前的最小化。一份要随浏览器 bundle 一起发布的 JSON 配置、嵌入到 JS 字符串里的 JSON、或任何字节数本身就重要的场景，最小化会把所有用于格式化的空白字符都去掉。

更广阔的工具生态里的 JSON

在命令行工作流里，jq（Stephen Dolan，2012 年首次发布）是 JSON 处理工具的代表，一个小巧、静态链接的二进制，既能格式化（jq .）、过滤（jq '.users[] | .email'）、做变换，也能用它自己那套简洁的表达式语言完成复杂查询。Python 的标准库里有 python -m json.tool 可以一行搞定 pretty-print。JavaScript 内置的 JSON.stringify(obj, null, 2) 在浏览器/Node 里是最快的格式化方式。JSON Schema（当前 draft 2020-12，由 Henry Andrews、Austin Wright、Greg Dennis 等人编辑）提供了一套词汇，用来声明一个 JSON 文档应该是什么形状（类型约束、必需属性、格式校验器、条件逻辑）并且是 API 契约校验、OpenAPI 3.x 规格、配置校验、基于 JSON 的表单生成的事实标准。JSONPath（Stefan Goessner，2007，于 2024 年 2 月被标准化为 RFC 9535）是 JSON 上类似 XPath 的查询语言，被 jq 较简单的子集以及 Postman、jsonpath-ng（Python）、AWS CLI 等工具使用。JSON-LD（W3C 推荐标准，当前 1.1 版本于 2020 年 7 月发布）在 JSON 上扩展出语义网中链接数据的约定，是 Google 推荐用于网页结构化数据标记的格式。JSON Patch（RFC 6902）和 JSON Merge Patch（RFC 7396）则定义了 JSON 文档上标准化的 diff/patch 格式。

Tree 视图，它为什么重要

一份哪怕只是中等大小（几百行）的 pretty-print JSON 文档，作为平铺文本去浏览也是相当吃力的。本工具里的 tree 视图把每一个对象和数组都折叠成一个可以展开的节点，让你只点开自己关心的那些层级，并且对于你点击的任何节点，都能看到它的 JSONPath 表达式。「点击就能拿到路径」这个功能，正是「我能在文档里看到我想要的值」和「我能写出代码去访问那个值」之间的实用桥梁，把这条路径粘到 jq 里、粘到一条 JSONPath 查询里、粘到 JavaScript 的方括号语法里、粘到 Postman 的测试断言里。对于嵌套很深的 API 响应（Stripe、Shopify、Salesforce，或者任何带有丰富领域模型的接口），tree 视图 + 拷贝路径就是把「我看到这个字段了」变成「我已经拿到访问表达式了」、只需两次点击的工作流。

隐私：仅在浏览器里完成校验

粘进格式化工具的 JSON 经常就是真实的生产数据，带用户标识符、会话令牌、内部实体 ID 的 API 响应；包含端点 URL 和功能开关的配置值。服务端的 JSON 格式化工具会把每一份输入都顺手存进它们自己的日志里。本工具用浏览器内置的 JSON.parse() 解析你的 JSON，再用 JavaScript 走完整个结构、把它重新输出为字符串，一切都在你的浏览器标签页内部完成。你点 Format 时打开 DevTools 的 Network 选项卡看一下（不会有任何请求被发出），或者在页面加载之后让它离线（飞行模式），格式化工具仍然能继续工作。对于生产环境的 API 响应、内部配置、含有令牌或密钥的 JSON，或任何你不希望被复制到陌生人硬盘上的文档来说，都是安全的。

常见问题

为什么我的 JSON 验证失败？

最常见的几类错误：在最后一个属性/元素之后留有结尾逗号（在 JavaScript 和 JSON5 里合法，在标准 JSON 里非法）；用了单引号而不是双引号（JSON 只接受 "）；键没加引号（JavaScript 对象字面量允许 {name: "Alice"}，但 JSON 要求 {"name": "Alice"}）；写了注释（JSON 没有注释语法，如果要写就用 JSON5 或 JSONC）；用了 undefined 这种值（JSON 只有 null）；缺少了某个括号；用了 NaN 或 Infinity 这类特殊浮点数（JSON 都不允许）。校验器报的错误消息会给出行号和列号；先去那里看一眼。

格式化和最小化有什么区别？

Format 会加上缩进、换行和空格，让 JSON 变得更好读；minify 则会去掉所有不必要的空白，让它尽可能小。两者的实际数据内容是一样的，JSON 解析器在语法层面就会忽略空白。开发、调试和代码审查时用格式化好的版本；HTTP 传输、嵌入到 JavaScript bundle 里的 JSON、或者任何字节数都很重要的场景，就用最小化版本。现代基础设施（HTTP 响应上的 gzip、CDN 边缘上的 Brotli）会非常激进地压缩 JSON，所以带宽差异看上去比实际大；但最小化版本本身仍然略小一些，解析也略快一些。

是否有大小限制？

没有硬性上限，实际上能处理多大取决于浏览器的可用内存。在现代设备上，10 MB 以内的文件格式化和校验通常都在不到一秒完成；50–100 MB 这个量级的文件可能会在 JSON.parse() 走完整个结构期间让标签页短暂卡一下。对于非常大的 JSON（GB 级别，通常是大型 API 导出或 NDJSON 日志转储），用命令行工具（jq、python -m json.tool、node -e）会更合适，因为它们可以做流式处理，而不是把整份文件全部加载到内存里。

「Sort Keys」是做什么用的，我什么时候应该用它？

Sort Keys 会把每个对象里的键按字母顺序递归地排好。数据语义不变（JSON 对象的键顺序按规范来说在技术上是未定义的，虽然大多数解析器会保留插入顺序）但输出会变得规范化。这在两种场景下特别有用：一是要 diff 两份语义上应该等价的 JSON（不排序的话，键顺序的差异就会造成噪声很大的 diff）；二是想要可重复的构建产物（同样的数据无论在内存里是怎么构造出来的，都应该能序列化成字节级一致的 JSON）。

我的 JSON 文档会被上传吗？

不会。所有解析、校验、格式化、排序和树视图渲染都是通过 JSON.parse() 和 JavaScript 在你的浏览器里完成的。你粘进来的 JSON 永远不会经过网络。点 Format 时打开 DevTools 的 Network 选项卡看一下（不会有任何请求被发出），或者在页面加载之后让它离线（飞行模式）。对于专有 API 响应、内部配置、含有令牌或会话数据的 JSON，或任何受 NDA 约束的内容来说，都是安全的。

相关工具