JSON压缩工具

使用方法

1. 把要压缩的 JSON 粘进左侧「输入 JSON 文本」。页面打开时已经放了一段带两空格缩进的订单服务配置（171 字符），可直接点「压缩」看效果。
2. 点「压缩」或按 Ctrl / Cmd + Enter。这是多行输入框，单独按 Enter 只换行不触发。
3. 右侧「压缩结果」立刻显示单行最小形式，同时上方五张卡片给出压缩率、原字符数、压缩后字符数和两边的 UTF-8 字节数。
4. 确认无误后点「复制结果」贴到别处，或点「下载 JSON」存成 .json 文件（不带 BOM，可直接被后端 JSON.parse 读）。JSON压缩工具跑完一趟后还可以对结果再压一次，用于确认已经压到最小。
5. 想还原成带缩进的可读版，请改用文末的格式化工具；本页只负责压缩方向。

这个JSON压缩工具能解决什么问题

接口返回、日志导出、配置下发这几条链路上的 JSON 通常带着两空格或四空格缩进，体积里塞的全是对解析毫无意义的空白。JSON压缩工具解决四件事：一是传输瘦身，示例里 171 字符的格式化配置压到 117 字符，省下 54 个字符、压缩率 31.6%，UTF-8 字节从 195 降到 141；二是统一出参，同一份数据无论写成两空格、四空格还是 Tab 缩进，压缩后得到的是逐字节相同的字符串，可以直接拿来做内容哈希或缓存键；三是找出冗余来源，对照表列出哪些写法在压缩过程中被改写，让你在源头就避免写出又长又易错的键名；四是暴露精度陷阱，12345678901234567890 会被解析成 12345678901234567000，压缩过程静默改了数值而没有任何警告。

本页只做压缩与体积统计。缩进美化、语法是否合法、键排序、两个 JSON 的差异对比，都不在这里做，请走文末分流。

原理和变量：为什么是 parse 再 stringify

核心只有一句：JSON.stringify(JSON.parse(输入))。两个参数都不传，走 ECMA-262 里 JSON.stringify(value) 的默认形式。

为什么不用正则删空白。正则分不清「语法空白」和「字符串里的空格」。对 {"s":" 空格 "} 做 replace(/\s+/g,'') 会把值里的两个空格一起删掉，输出 {"s":"空格"}——数据被改了，而且改得没有任何提示。走 parse 之后，语法空白在解析阶段就被丢弃，字符串值被完整保存在对象里，stringify 只负责按标准重新输出，值一个字符都不少。

第二个参数为什么必须空着。JSON.stringify 的第二参是 replacer，传 undefined 或不传都表示「保留全部键」。但如果误传一个数组，比如 JSON.stringify(o, ['a'])，实测 {"a":1,"b":{"c":2}} 会变成 {"a":1}，b 被整个丢掉；如果传函数 function (k, v) { return k === 'b' ? undefined : v }，结果同样是 {"a":1}。这两处是真实的数据丢失，不是显示问题。

第三个参数为什么不给。第三参是缩进。实测传 null, 0 和不传等价；传 null, 2 就变回带两空格的格式化文本；传 null, 11 会被规范截到 10 个空格；传 null, -1 等同于 0；传字符串 ' ' 则用空格本身填充。压缩场景下唯一正确的选择就是不传。

字符数与字节数的区别。统计用两组口径：字符数取 String.length，按 UTF-16 码元计；字节数用 TextEncoder.encode() 的 byteLength。示例原文 171 字符但占 195 字节，差 24 字节来自「订单服务」等 8 个汉字——每个汉字在 UTF-8 里占 3 字节而只算 1 个字符。真正决定网络流量的是字节数，所以两个数都给你。

遵循的规范。JSON 语法由 ECMA-404 定义，交换格式由 RFC 8259 定义。本页不做任何超出这两份文档的宽松处理：尾逗号、单引号、注释、未加引号的键名一律报错，而不是猜测作者意图。

完整示例（数值仅作演示）

打开页面时输入框里是这段用两空格缩进的订单服务配置，JSON压缩工具输出的最小形式是：

{"name":"订单服务","version":"2.1.0","features":["限流","熔断","灰度发布"],"limits":{"qps":1200,"timeoutMs":3000},"enabled":true}

五张卡片分别是：压缩率 31.6%、原字符数 171、压缩后字符数 117、原 UTF-8 字节 195、压缩后字节 141。

把同一份数据改写成四空格缩进或 Tab 缩进（138 字符），压缩结果与上面逐字节相同；对已经压好的文本再压一遍，省下 0 个字符。这就是幂等性：压缩两次等于压缩一次，可以放心放在构建流程里反复跑。

体积构成上，示例里 features 这个键连值加引号共 31 字符，limits 子对象共 40 字符，而 enabled 只占 16 字符——长数组和嵌套对象才是压缩后的大头，缩进省下来的反而是零头。

输入范围与对照表

压缩过程会改写以下写法（前 12 行默认显示，点「加载更多改写规则」展开余下 2 行）。这一列是本页最该记住的部分：压缩不是纯删空白，有些值会被规范化。

不同排版风格能省下多少，同一份 {"a":1,"b":2,"c":[1,2,3]} 为例：

边界与精度

体积阈值分两档。输入超过 200 KB（204800 字节）时先在提示区说明「已进入大文本处理」，让用户知道会有短暂停顿；超过 2 MB（2097152 字节）直接拒绝并报错，提示改用命令行工具。参考量级：2 万条记录的数组格式化后约 1482 KB，本页压缩后约 818 KB、压缩率 44.8%，Node 侧实测耗时 9 毫秒——单页内跑得动，但再大就会让标签页卡住，所以设了硬上限。

最危险的边界是数字精度，不是体积。JSON 的数字字面量在 JSON.parse 里直接落成 IEEE 754 双精度数，安全整数上限是 253-1 = 9007199254740991。所以 12345678901234567890（订单号、雪花 ID 常见）会被解析成 12345678901234567000，末位被静默改掉，压缩过程不报任何错。长 ID 必须写成字符串，这是唯一可靠的做法。另一个方向的坑是 1e400：解析得到 Infinity，而 JSON 没有 Infinity，stringify 会写出 null。

BOM 绝不能带。实测 JSON.parse('\ufeff{"a":1}') 直接抛 SyntaxError: Unexpected token，因为 U+FEFF 不是 JSON 合法字符。所以本页「下载 JSON」写出的文件首字节是 7b（{），不带 ef bb bf。本页的 CSV 导出是另一回事——那是给 Excel 看的表格，必须带 BOM，否则中文列名会乱码。

每条非法输入都指名报错。空输入报「输入框是空的」；带尾逗号 {"a":1,} 报「第 7 个字符附近多了逗号」；单引号 {'a':1} 报「JSON 的键和字符串都必须用双引号」；{"a":01} 报「第 6 个字符处的前导零不合法」；{"a":1} {"b":2} 报「第 8 个字符后有多余内容，一个 JSON 只能有一个顶层值」。全部给出位置和改法，不静默返回空串。

常见问题

相关工具

• JSON格式化工具：压缩的反向操作，把单行文本按指定缩进展开成可读结构。
• JSON校验工具：只判断语法是否合法并定位错误行号，不改动文本。
• JSON美化打印：面向终端查看的着色打印，压缩前想先看清结构时用。
• JSON按键排序工具：按键名排序后再压缩，输出稳定，适合拿来做缓存键。
• JSON行转换器：把 JSONL 每行单独解析，便于定位坏行。
• 图片压缩工具：另一类体积优化，处理的是二进制资源而非文本。
• 开发者工具：查看全部开发者工具。