已更新9月 2026
✓ Valid JSON
✗ Invalid
如何使用JSON 缩小器
- 将格式化的 JSON 粘贴到输入中。
- 读取缩小的输出 - 一行，相同的数据，显示大小节省。
- 单击复制并发送它 - API 响应、嵌入式配置、存储值。
- 要稍后读取，粘贴到 JSON 格式化程序中 - 往返是无损的。
JSON 缩小器是什么？
JSON 压缩器会去除 JSON 语法不需要的每个字节——缩进、换行、冒号和逗号后的空格——将打印精美的文档折叠成一行密集的行。数据未受影响：{"name": "Ada", "age": 36} 漂亮地打印了四行，并将其缩小的孪生解析为完全相同的对象。
节省的规模是真实的：缩进通常会为深层嵌套文档增加 20-40%，对于服务于捆绑包内提供的数千个响应或配置的 API，这些纯粹是浪费的字节 - 人眼和机器都存在空白没在找。
关于JSON 缩小器
粘贴格式化的 JSON 并立即获得缩小的单行版本，显示节省的大小和从剪贴板单击一下的结果。
缩小的 JSON 所属的位置：API 响应和请求正文（许多框架在调试模式下漂亮地打印并忘记停止）、嵌入 HTML 页面或 JS 包中的 JSON（配置 blob、初始状态）、按字节付费的存储（localStorage 的 ~5 MB 预算、Redis 值、日志管道），以及Webhook 有效负载。没有的地方：任何人类读取或比较的内容 - git 中的配置都会保持漂亮的打印状态，以便代码审查有效。
往返过程是无损且免费的：缩小到发布，当您需要再次读取它时，JSON 格式化程序会完美地反转它 - 空格是您总能找回的一件事。
常见问题解答
不——只有令牌间的空白。字符串保留其内部空间（它们是数据），数字和结构保持不变，并且任何解析器都会以相同的方式读取两个版本。
对于缩进文档，通常为 20-40% — 更深的嵌套意味着需要去除更多的缩进。 gzip 之后，相对增益缩小，但解析端字节和未 gzip 压缩的上下文（localStorage、日志）保持完全节省。
是的——生产 API 永远不应该在缩进上花费带宽。大多数框架默认缩小并提供 ?pretty=1 样式标志用于调试；如果您的响应是缩进的，则序列化器设置是错误的。
否 — 人类编辑和审查的文件（package.json、tsconfig）保持格式化；差异和合并取决于它。如果字节很重要，请在构建/部署时进行缩小，以保持源代码的可读性。
当有效负载巨大且热门时：消息包/协议缓冲区会进一步缩小大小并缩短解析时间，但会牺牲人类可读性和工具。对于大多数 Web API，缩小 + gzipped JSON 是最佳选择。