工具用的顺手吗？
你的反馈能帮助我们做得更好
移除JSON中冗余空白字符，将格式化数据压缩为紧凑单行，提升传输效率。
概览
了解工具能解决的问题、计算或处理逻辑，以及数据边界。
JSON 是用于表示结构化数据的文本格式。经过缩进的 JSON 便于阅读，但键、冒号、逗号、括号周围的空格和换行会增加文本长度。压缩工具读取有效 JSON，再把解析后的数据序列化为紧凑文本，便于粘贴到请求示例、配置片段或日志中。它不会执行 Gzip 等二进制压缩，也不会加密内容。
RFC 8259 规定，JSON 结构符号周围允许出现特定空白字符；字符串内的字符则是字符串数据的一部分。查看 IETF RFC 8259。因此，压缩不是把文本里的所有空格机械删除：例如字符串值 "New York" 中的空格必须保留。
输入 {"name": "Lin", "count": 3}，紧凑输出为 {"name":"Lin","count":3}。键和值的结构保持可解析，但用于阅读的缩进和换行不保留。工具对输入先执行 JSON 解析，语法不合法时会显示错误，而不是把任意文本当作 JSON 压缩。
由于输出是解析后重新序列化，原文本的空白、排版以及某些数字文本写法可能变化；例如科学计数形式可能被标准化为另一种数值写法。若你需要逐字保留源文件格式或比较原始文本差异，应保留原件。
JSON 最小化只去除展示排版带来的冗余字符，结果仍是普通文本 JSON。Gzip、Brotli 等传输压缩会对字节流编码，通常需要由传输双方支持对应解压方式。最小化后的字符数可能减少，但实际网络体积还取决于编码方式、HTTP 压缩和内容本身，不宜把某个固定缩减比例当作保证。
RFC 8259 的语法支持对象、数组以及字符串、数字、布尔值和 null 等 JSON 值；因此输入不一定非要是对象，也可以是合法数组或标量文本。
指南
按步骤完成操作，并通过示例核对输入与结果。
准备完整且语法有效的 JSON 文本，可以是对象、数组或其他合法 JSON 值。
将文本粘贴到输入区，或载入页面提供的示例。
确认处理模式为“压缩”。输入发生变化后，工具会自动处理并显示输出；如有语法错误，先按提示修正输入。
核对输出内容后，可复制结果，或使用页面提供的下载操作保存文本。
例如输入带缩进的对象 {"name": "Lin", "count": 3}，输出会把结构之间的空白收紧为 {"name":"Lin","count":3}，字符串里的有意义空格则保留。
场景
查看这项工具在不同工作与生活流程中的用法。
调试人员可将易读的接口请求样例压缩为紧凑文本，粘贴到只接受单行内容的终端或表单中；执行前仍应检查转义和字段值。
需要把 JSON 放进文档或测试夹具时，可先保留一份格式化源文件，再生成紧凑副本用于目标环境。
分析者可将语法有效的 JSON 统一序列化后再检查结构差异。若要比较数字原始拼写或空白差异，应改用文本级对比。
问答
集中解答高频疑问与容易混淆的问题。
字符串值内部的空格属于数据，应被保留；工具压缩的是 JSON 结构排版空白。比如 "New York" 仍包含中间的空格。
输入必须是有效 JSON。检查键名是否使用双引号、逗号和括号是否配对，以及末尾是否多出逗号；注释也不是 RFC 8259 JSON 语法的一部分。
数据结构可再次格式化显示，但原来的缩进宽度、换行位置和排版习惯不会被记录。需要保留原貌时，请保存格式化源文本。
它会去掉 JSON 的展示排版空白，但实际传输体积还受字符编码和网络层压缩影响。此功能本身不生成 Gzip 等压缩文件。
须知
使用前了解适用范围、结果限制与必要提醒。
紧凑输出较难人工阅读，重要文件建议另存原始格式化版本。重新序列化可能改变空白和数字字面量的书写形式，因此若需要字节级一致、签名校验或原文审计，应使用符合该任务要求的专门流程。粘贴数据前也要确认其中不含不应在当前环境处理的密钥、个人信息或业务机密；不要根据本工具的处理结果推断数据已加密或受到保护。
推荐
查找相关工具、专题与可用的 API 能力。
