关于 JSON 格式化
JSON（JavaScript 对象表示法）是 Web 上最常见的数据交换格式。来自 API 的 JSON 通常是压缩的——全在一行且没有空格——难以阅读。美化添加一致的缩进，便于浏览其结构。
压缩删除所有不必要的空白，减少传输文件大小。验证检查文本是否是语法正确的 JSON：括号匹配、带引号的键、逗号位置和值类型。
JSON 格式化工具
粘贴 JSON，一键美化、压缩或验证。
怎么格式化或压缩 JSON?
格式化 JSON 时,把文本解析成数据结构,再用统一的换行和缩进(常见为 2 个空格)重新输出;压缩时则把同一结构重新输出,不带任何多余空白。例:{"a":1,"b":2} 格式化后变成 4 行、每层缩进 2 个空格的结构,压缩后又变回 {"a":1,"b":2}。
JSON 格式化、压缩与校验步骤
- 把原始 JSON 文本粘贴到输入框中。
- 格式化时,工具把文本解析成对象/数组结构,再按每个键或数组项一行、缩进 2 个空格的方式重新输出。
- 压缩时,工具解析同一结构,再输出时不带任何换行或多余空格,只保留合法语法所需的字符。
- 校验时,工具尝试直接解析文本而不重新格式化;解析成功就说明这段 JSON 语法合法。
- 如果解析在某一步失败,会给出具体原因(意外的符号、缺少逗号、括号不匹配),方便你定位并修正错误。
格式化与压缩的区别
格式化:parse(文本) -> stringify(值, 缩进=2) | 压缩:parse(文本) -> stringify(值, 缩进=0)
- parse = 把 JSON 文本转换成内存中的对象、数组、字符串、数字、布尔值或 null
- stringify = 把该结构重新转换回 JSON 文本,可选择是否带缩进
格式化与压缩结果示例
| 输入 | 格式化后(缩进 2 空格) | 压缩后 |
|---|---|---|
| {"a":1,"b":2} | {⏎ "a": 1,⏎ "b": 2⏎} | {"a":1,"b":2} |
| [1,2,3] | [⏎ 1,⏎ 2,⏎ 3⏎] | [1,2,3] |
| {"x":{"y":true}} | {⏎ "x": {⏎ "y": true⏎ }⏎} | {"x":{"y":true}} |
常见问题
为什么看起来正确的 JSON 却被判定为无效?
常见的隐藏错误包括最后一项后面多了一个逗号、用单引号而不是双引号包裹键和字符串,或者键没有加引号——这些在 JavaScript 对象字面量里都合法,但在严格的 JSON 中不允许。校验器遵循严格的 JSON 语法,即使文本看起来很像合法的 JavaScript,也会判定失败。
JSON 和 JavaScript 对象有什么区别?
JSON 是一种语法严格的文本数据格式:键必须是双引号字符串,不允许末尾多余逗号,且只允许固定的几种值类型(字符串、数字、布尔值、null、对象、数组)。JavaScript 对象字面量的语法更宽松,还允许不加引号的键、末尾逗号、函数和注释,而这些都不是合法的 JSON。
压缩会改变 JSON 表示的数据吗?
不会。压缩只是去掉不属于任何字符串值的空白字符,解析出的数据结构以及它所表达的含义在压缩前后完全一致,只是传输或存储所需的字节数发生了变化。
这个工具能处理层级很深的嵌套 JSON 吗?
可以。格式化功能对任意深度的对象和数组都会递归处理,每深入一层就多缩进 2 个空格,无论结构嵌套多深,可读性都能保持。
本工具按 RFC 8259 定义的标准 JSON 进行校验和重新格式化,不支持 JSON5、JSONC(带注释)等宽松的 JSON 变体;体积很大的输入(几兆字节以上)在浏览器中处理可能会比较慢。
Sources: RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format, ECMA-404 - The JSON Data Interchange Syntax
隐私与安全
- 在浏览器中计算 — 您输入的内容仅在本机设备上计算，不会发送到 utilduck 服务器。
- 加密连接 — 所有页面均通过 HTTPS 提供，传输过程中无法被读取。
- 不提供给第三方 — 您输入的内容不会传递给分析或广告服务。
- 不保存 — 计算结果不会保存到任何服务器，也无需注册账号。
最后更新: 2026-08-24
通过语法校验只是JSON检查的第一层
格式化会添加缩进与换行，压缩会删除不影响语法的空白，正常情况下都不应改变JSON表示的数据。若解析失败，应从错误位置附近检查双引号、逗号、括号、反斜杠和控制字符，并记住JSON并不接受所有JavaScript对象写法。先保存未修改原文，再做最小修正；不要一次自动替换大量引号或删除换行，否则可能掩盖数据在上游被截断的问题。格式化前后可在目标解析器中分别读取并比较数据结构，而不是只看页面排版更整齐。
语法正确后，还要依据目标API或Schema检查键名、必填字段、类型、允许值和嵌套关系。重复键在不同解析器中可能被覆盖或拒绝，超大整数和小数也可能因运行环境的数值模型失去精度；对象键顺序通常不应被当作业务含义。日志、配置和接口响应可能包含令牌、个人资料或内部地址，粘贴前应依组织政策脱敏。页面不会调用实际API、验证签名或证明数据可信。提交前要在消费该JSON的程序中运行Schema、单元测试和安全检查，并为大型文件考虑内存与超时限制。若需要稳定比较输出，不要假设格式化后的键顺序等于来源顺序，应先定义规范化方案。错误信息也可能包含原始数据片段，复制到工单前同样要脱敏，并用最小可复现样例替代整份生产响应。