工具使用常见问题：数据、文件与导出

结论：本站的解析、格式化、对比与查询全部在浏览器本地执行，断网后仍可使用；处理完敏感数据请清空 localStorage 历史记录；文件超过 10 MB 改用本地命令行与流式工具，不要硬粘进浏览器。

把敏感报文粘进在线工具之前，先弄清它会去哪。这一篇只谈工具的运行时行为，不谈语法。

一、数据与隐私

JSON 在线格式化会把数据上传到服务器吗？

不会。解析、格式化、压缩、对比、查询全部在浏览器里完成，页面不向业务服务器发送你粘贴的任何内容。

判断一个在线工具是否上传数据，不用看它的隐私声明，看浏览器的网络面板就够：

1. 打开开发者工具，切到 Network 面板，勾选保留日志；
2. 粘贴一段 JSON，点「格式化」；
3. 观察是否出现新的 XHR 或 fetch 请求，请求体里是否包含你的内容。

真正本地处理的工具，这一步只会看到静态资源请求。反过来，如果一次格式化出现了 POST /api/format 并且请求体是你的原文，那不管页面怎么写，数据都已经离开浏览器了。

本站所有工具都是纯前端实现，构建产物里没有服务端接口。断网后刷新过缓存仍然可以继续使用， 这也是判断「是否纯本地」最直接的办法。

断网了还能用吗？

能用，前提是页面已经加载过一次。

工具站的资源随首次访问下载到浏览器缓存，之后即使断网，格式化、压缩、JSON5 转换、 JSONPath 查询仍然照常工作。会失效的只有依赖网络的功能，例如检查新版本、下载桌面端安装包。

反过来，断网测试也是验证「数据不外传」的好方法：断网后如果功能全废，说明每次操作都在请求服务端。

数据会保存在本地吗？怎么清除？

会，但只保存在当前浏览器的 localStorage 里，而且只有历史记录与界面设置两类。

• 历史记录：最近 100 条处理记录，按时间倒序，用于回溯上一次粘贴的数据；
• 界面设置：主题、语言、缩进偏好等；
• 不会保存的：文件本身、上传记录、任何带身份标识的内容。

清除方式有三种，效果从窄到宽：

在共用电脑上处理生产数据，处理完直接清空历史，不要只关标签页——localStorage 不会随标签页关闭而消失。

为什么中文变成了 \u4e2d\u6587？

因为「转义」功能把非 ASCII 字符转成了 Unicode 转义序列，这是刻意行为，不是乱码。

\u4e2d 就是「中」字的码位（U+4E2D）。两种形式在 JSON 语义上完全等价，解析后都是同一个字符串：

复制{
  "escaped": "\u4e2d\u6587",
  "plain": "中文"
}

什么时候需要转义？把 JSON 嵌进只接受 ASCII 的老系统、写进 HTTP 头、或者塞进另一层字符串时。 什么时候不需要？绝大多数接口传输、文件存储都不需要，UTF-8 直接存中文更省字节——一个汉字 3 字节， 转义后变成 6 字节。

看到中文变 \u4e2d，先去检查是不是点了「转义」按钮，而不是怀疑编码坏了。

二、文件与大小

支持多大的文件？

浏览器端没有硬性上限，真正的限制来自三处：

也就是说，几十 MB 的文件「能解析」但「不好用」。真正需要处理这类数据时，正确做法不是换个更强的在线工具， 而是改用流式处理（见 性能与安全常见问题）。

经验阈值：2 MB 以内在线工具很顺畅；2–10 MB 要接受一两次卡顿；超过 10 MB 建议本地脚本处理。

粘贴后浏览器卡住不动了，怎么办？

先别刷新——刷新会丢掉内容，还得重新粘贴。按下面的顺序抢救：

1. 等 10–30 秒。多数情况是主线程在解析或渲染，会自己恢复；
2. 恢复后立刻切到「压缩」视图或关闭树形展开，减少 DOM 节点；
3. 把内容复制到本地文件，改用命令行处理：

复制# 只看前 100 行结构，避免整体加载
head -c 200000 data.json | jq . | head -n 100

# 用流式工具统计条数，不进内存
jq -c '.items[]' data.json | wc -l

下次遇到大文件，先用 wc -c 看字节数，再决定要不要往浏览器里粘。

为什么粘贴进来格式没变？

常见三种原因，按出现频率排序：

1. 输入本身已经是压缩格式，且没有语法错误：格式化只会调整缩进，如果原文本来就两行， 格式化后仍然两行——因为字符串里的换行不会被展开；
2. 内容不是 JSON：比如粘的是 JavaScript 对象字面量（键名没引号、用了单引号）， 解析器会直接报错而不是格式化；
3. 点错了按钮：压缩与格式化是两个方向，压缩会把缩进全去掉。

判断方法：看输出区右上角的字符数。格式化后字符数应该增加（多了缩进与换行）， 如果反而减少，说明执行的是压缩。

三、输入与输出

怎么把结果导出成文件？

三种方式，按可靠性排序：

下载生成的文件默认用 UTF-8 编码、无 BOM。这一点很重要：带 BOM 的 JSON 在很多解析器里会直接报错 （见 语法与格式常见问题 里关于 BOM 的那一节）。

支持 JSON5 和 JSONC 吗？

支持，但要区分「解析」与「输出」两件事。

• 输入侧可以贴 JSON5（单引号、无引号键名、注释、尾逗号、十六进制数字）或 JSONC（只允许注释）；
• 输出侧可以转成标准 JSON，也可以反向把标准 JSON 转成 JSON5 便于人工编辑。

跨系统传输时务必输出标准 JSON。JSON5 是给人写配置用的方言，Content-Type: application/json 的请求体里出现注释或尾逗号，服务端多半会拒绝。

四、环境与兼容

手机上能用吗？

能，界面按单列重排，格式化、压缩、对比、JSONPath 都保留。

但手机上处理大文件体验很差：软键盘遮挡、选中文本困难、切后台时浏览器可能回收页面导致内容丢失。 应急可以，日常建议在电脑上做。

为什么同一个文件在 Chrome 能打开，在 Safari 报错？

多数不是浏览器差异，而是编码差异。按这个顺序排查：

1. BOM：Windows 记事本保存的 UTF-8 带 BOM，部分解析器不容忍；
2. 换行符：CRLF 与 LF 混用本身不影响 JSON，但会让错误行号错位，看起来像「报错位置不对」；
3. 不可见字符：从网页复制的文本可能带零宽空格（U+200B），肉眼看不见但会让键名对不上。

用一个命令就能看穿：

复制# 看前 16 字节的十六进制，EF BB BF 开头就是带 BOM
head -c 16 data.json | xxd

五、速查