MT
My Toolbox

JSON 格式化工具 — 在线格式化、验证和调试 JSON

把乱成一团的 JSON 粘贴进来，马上得到整齐的输出。格式化、验证、压缩全在浏览器里完成，数据不会发到任何服务器。如果 JSON 有语法错误，工具会告诉你具体哪一行出了问题。

输入 JSON
在此粘贴您的 JSON 数据
输出
格式化的 JSON 结果

一分钟了解 JSON

JSON（JavaScript Object Notation）是服务器和浏览器之间传数据的标准格式。你调过的每个 REST API 返回的都是 JSON，你电脑上的 package.json、tsconfig.json、.eslintrc 也都是 JSON。

格式本身很简单——对象用花括号，数组用方括号，字符串必须双引号。但简单归简单，坑不少：不能写注释，末尾不能有逗号，少一个逗号整个文件就废了。所以你需要一个带验证功能的格式化工具。

JSON 的正式规范是 RFC 8259（2017 年 12 月发布），整个规范只有 16 页。最容易踩的坑：对象的 key 必须是双引号字符串。{name: "张三"} 在 JavaScript 里没问题，但不是合法的 JSON。另一个冷知识——JSON 其实不是 JavaScript 的严格子集，U+2028 和 U+2029 这两个字符在 JSON 字符串里合法，但在 ES2019 之前的 JS 字符串里是非法的。

使用方法

  1. 把 JSON 数据粘贴到左侧输入框。
  2. 选缩进方式——2 空格（JS/TS 项目常用）或 4 空格（Python 项目常用）。
  3. 点"格式化"美化输出，或点"压缩"去掉所有空白。
  4. 复制结果。如果有错误，验证器会高亮具体的行号和字符位置。

什么时候会用到

调试 API 返回值

fetch() 返回一坨 2000 字符的字符串，粘贴进来一秒看清嵌套结构。比在控制台写 console.log(JSON.stringify(data, null, 2)) 快多了，尤其是要对比多个接口返回的时候。

部署前验证配置文件

CloudFormation 模板里多了个逗号？那就是 20 分钟的部署失败。推代码之前把 JSON 配置粘贴进来验证一下，编辑器的语法高亮经常漏掉这种错误。

整理数据库导出

MongoDB 导出和 Firestore 导出都是巨大的单行 JSON。格式化之后才能找到那个导致迁移脚本崩溃的 null 字段。

给文档准备 JSON 示例

要在 API 文档或 README 里放一段 JSON 示例？格式化成 2 空格缩进，复制，粘贴到 markdown 代码块里，5 秒搞定。

实用经验

1.

解析前一定要验证

JSON.parse() 外面一定要包 try-catch。生产环境里一个未捕获的 JSON 解析错误会直接让 Node 进程崩溃，或者给用户一个白屏。

2.

小心复制粘贴的编码问题

从 Slack/Word 复制来的"智能引号"（“” 而不是 ""）、Windows 记事本的 BOM 字符、网页里的不间断空格——这些都会让看起来没问题的 JSON 报错。如果验证器说第 0 个字符就有错，八成是不可见字符的问题。

3.

知道什么时候不该用在线工具

超过 10MB 的文件用命令行的 jq。CI 流水线里自动格式化用 prettier 或 python -m json.tool。这个工具适合在工位上快速调试，不适合自动化场景。

4.

2 空格还是 4 空格

JSON 规范不管这个。但 JS/TS 项目绝大多数用 2 空格（看看任何热门开源项目就知道了），Python 项目一般用 4 空格。选一个，团队统一就行。

实际示例

嵌套的 API 响应

一个典型的用户信息接口返回——传输时是压缩的单行格式。

Input

{"id":42,"name":"张三","email":"[email protected]","roles":["admin","editor"],"preferences":{"theme":"dark","locale":"zh-CN","notifications":{"email":true,"push":false}},"lastLogin":"2026-05-10T14:30:00Z"}

Output

{
  "id": 42,
  "name": "张三",
  "email": "[email protected]",
  "roles": [
    "admin",
    "editor"
  ],
  "preferences": {
    "theme": "dark",
    "locale": "zh-CN",
    "notifications": {
      "email": true,
      "push": false
    }
  },
  "lastLogin": "2026-05-10T14:30:00Z"
}

无效 JSON — 找出错误

乍一看没问题，但有一个末尾逗号会导致解析失败。

Input

{"users": [{"name": "Alice", "age": 30,}, {"name": "Bob", "age": 25}]}

Output

错误位置 38：意外的 '}' 字符。"30" 后面的逗号在 JSON 中不合法，删掉这个逗号即可修复。

功能特点

  • 支持 2 空格或 4 空格缩进，随你选
  • 验证错误精确到行号和字符位置
  • 一键压缩，适合生产环境使用
  • 100% 浏览器端运行，数据不会发送到任何地方
  • 实测处理过 50MB 的 MongoDB 导出文件
  • 不用注册，没有广告，不追踪用户

常见问题

JSON 看起来没问题但解析器报 "unexpected token" 是怎么回事？

十有八九是这几个原因：(1) 末尾逗号——{"a": 1,} 不合法；(2) 用了单引号——JSON 只认双引号；(3) key 没加引号——{name: "张三"} 是 JS 语法不是 JSON；(4) 写了注释——标准 JSON 不支持 // 和 /* */。如果你需要注释，可以了解一下 JSONC 或 JSON5。

有文件大小限制吗？

我们这边没有硬性限制——它跑在你浏览器的内存里。Chrome 大概能处理到 100MB 左右，再大标签页就会崩。超过 10MB 的建议用命令行工具 jq 或 fx，性能好得多。

这个工具会把我的数据发到服务器吗？

不会。页面加载完之后零网络请求。不信的话打开 DevTools → Network 标签页，粘贴 JSON，点格式化——你会看到什么请求都没有。整个工具就是纯客户端 JavaScript。

JSON 和 JSONC 有什么区别？

JSONC（JSON with Comments）允许 // 和 /* */ 注释，也允许末尾逗号。VS Code 的 settings.json 和 tsconfig.json 用的就是 JSONC。但标准 JSON 解析器会拒绝 JSONC——你需要专门的解析器比如 jsonc-parser 这个 npm 包。

JSON 为什么不允许末尾逗号？

这是规范的刻意设计，为了让解析逻辑简单明确。JavaScript 允许，Python 也允许，但 JSON 不行。实际开发中大部分"无效 JSON"错误都是因为开发者以为 JSON 和自己用的编程语言规则一样。

使用技巧与相关工作流