Herramienta JSON
Seis operaciones —formatear, minimizar, validar con posición, ordenar claves, escapar y pasar a CSV— comparten una entrada: cambias una y revalidas
// 与 /* */）、单引号字符串、尾随逗号、NaN / Infinity、以及未加引号的对象键——这些都是 JSON5 或 JavaScript 对象的写法，不是 JSON 标准的一部分，解析器拒绝它们是正确行为。本页不提供"宽松模式"：把非法输入偷偷"修好"会让你以为数据入库时也会通过，风险比报错大得多。
Entrada
粘贴 JSON，或点右侧按钮填入示例操作
格式化只做「重新排版」，不会改变值的类型，也不会给键排序——取消勾选「保留键的原始顺序」才会按键名重排（与「键排序」一致）。输出会给出字符数与行数。
Resultado
JSON 格式化、校验与转 CSV 里最容易踩的几件事
严格 JSON 的语法其实只有几页纸，但报错信息几乎没法读。RFC 8259 定义的 JSON 只有六种结构：对象 { }、数组 [ ]、字符串、数字、布尔值 true / false、以及 null。对象必须是「字符串键 + 冒号 + 值」，键必须用双引号；数组元素之间必须用逗号分隔，且最后一项后面不能再有逗号；字符串里除了少数字符外都不能直接出现控制字符。规范很短，可浏览器和多数语言抛出的错误却只是「Unexpected token } in JSON at position 42」——它只说第 42 个字符处出了意外，不告诉你第 42 个字符在第几行。本页做的就是把那个字符位置换算成「第 X 行第 Y 列」，同时在输入框里选中出错位置，让你一眼看到问题在哪。
尾随逗号、注释、单引号为什么必须报错。这是三个最常见的「看起来没问题」的写法：{ "a": 1, }（尾随逗号）、// 说明 或 /* 说明 */（注释）、{ 'a': 1 }（单引号）。它们全都是 JSON5 或 JavaScript 对象字面量的扩展，不是 JSON。JSON 的设计目标之一是「用极小的解析器就能正确读出」，因此它刻意不允许这些方便写法：注释会让同一份数据在没有注释语法的解析器里直接失败，尾随逗号会让「按逗号切分再逐段解析」的流式解析器多出一个空段。更麻烦的是，很多 JavaScript 环境（包括浏览器控制台、eval、以及 JavaScript 配置文件）会接受它们，于是同一段文本在本地「没问题」、发到服务端或换个语言解析时就炸。本页站在严格 JSON 这一边：宁可现在报错，也不要让它到生产环境才暴露。同样地，NaN 与 Infinity 在 JSON 里也不是合法值——需要表达「非数」时请用 null 或字符串。
格式化与压缩各自解决什么问题。格式化（缩进 2 空格 / 4 空格 / Tab）是为了给人看：代码评审、配置比对、排查层级关系。这里有一个容易被忽略的细节——格式化不应该改变键的顺序。有些工具会顺手把键按字母排序，看起来整齐，但「字段顺序」在不少场景下是有意义的（日志字段的自然阅读顺序、接口文档的示例顺序、以及对比两份文件的差异），悄悄重排会让 diff 噪点暴增。本页默认保留原始顺序，需要排序时请显式点「键排序」。压缩（minify）则是为了给机器传：去掉缩进与换行后体积通常能小两三成，放进请求体、环境变量或配置文件里更省事。注意压缩只删「结构上的空白」，字符串内部的空格与换行会被完整保留，所以压缩后解析出来的数据与压缩前完全等价。
转 CSV 的坑几乎全在「值里有逗号、引号、换行」和「编码」上。CSV 看起来很土，但它有一个所有表格软件都认的正式规范 RFC 4180。规范里真正的难点只有一条：当某个单元格里出现逗号、双引号或换行时，必须用双引号把整格包起来，并把格内的每个双引号写成两个。少了这一步，一个地址里的逗号就会把整行拆歪；多写一层引号又会多出真实的引号字符。另外三件事同样常见：① 表头要取所有对象的键的并集（接口返回的数组里，元素往往不是每个都有全部字段），缺字段的位置留空而不是错位；② Excel 在简体中文 Windows 上双击打开无 BOM 的 CSV 时会按本地代码页解读，中文直接乱码，因此本页默认在文件开头写入 UTF-8 BOM；③ 数字与文本的界线——CSV 没有类型，007 与 7 到了表格里都会被当数字，需要保留前导零时得在导出前把它变成带引号的文本。本页严格按 RFC 4180 处理这三类字符，嵌套对象与数组会写成一格紧凑 JSON，而不是被压平成多列（压平会丢失结构与层级信息，宁可让你再处理一次）。
为什么不上传到服务器。JSON 是最容易夹带敏感内容的格式：接口返回里可能有 token、数据库配置、内网地址、用户的手机号与身份证号，运维配置文件里往往还有密钥。把这样一段文本粘进一个在线格式化工具，如果它在服务端解析，你就等于把凭证复制了一份给第三方——而且很多站点的"历史记录"会把它留在数据库里。本工具的全部逻辑（解析、定位、排序、转义、转 CSV）都是运行在你浏览器内的一段纯 JavaScript 函数，写在页面的 PURE 区块里，可以用开发者工具的 Sources 面板逐行读完；整页没有任何提交请求，也没有写入 localStorage 或 cookie 的历史记录。断网状态下刷新页面，它照样能用。
Preguntas frecuentes
position es un desplazamiento de carácter contado desde el carácter 0 (en V8 se cuentan unidades de código UTF-16: el chino y la puntuación de ancho completo valen 1, los emoji y demás caracteres del plano suplementario valen 2); no es un número de línea. Esta página lo convierte a fila y columna y muestra un trozo de contexto, p. ej. «cerca de fila 3, columna 15: "age": ,». Además selecciona ese punto en la caja de entrada y desplaza hasta él. Si el mensaje de algún navegador no trae posición, la página dice con honestidad «no puedo localizarlo, pero esto no es JSON válido» — jamás te inventa una posición.
Porque esas herramientas usan análisis permisivo (JSON5, JSONC o directamente eval). Son cómodas, pero el resultado es que el mismo texto falla en el json.loads de Python, en Jackson de Java y en encoding/json de Go: las escrituras a base de datos, el reenvío de la pasarela y los consumidores de colas se rompen en ese instante. Esta página se mantiene en el RFC 8259 estricto para que lo descubras en el momento de pegar, no después de publicar. Apunte: el settings.json de VS Code y el tsconfig.json de TypeScript admiten comentarios porque leen JSONC (JSON with Comments), no JSON estándar.
Depende de si tu entrada ya estaba fuera del límite de precisión de JavaScript. JSON.parse resuelve los números como flotantes de doble precisión IEEE 754, así que los enteros por encima de 2 elevado a 53 (ciertos IDs de algoritmo copo-de-nieve, números de pedido de 19 dígitos) ya están falseados en el instante del análisis: formatearlos después sale falseado también, y esta página tampoco puede recuperarlos. Para esos casos, haz que tu API devuelva los IDs como cadenas. Aparte: formatear y comprimir solo re-maquetan el texto; no convierten 1.0 en nada distinto de 1, ni cambian el orden de las claves (salvo que pulses expresamente «ordenar claves»).
Porque CSV es una tabla de dos dimensiones - una fila por registro - y necesita «un conjunto de registros con la misma forma». Si la raíz es un objeto (p. ej. { "total": 3, "rows": [ ... ] }), esta página dice claramente que no lo soporta en vez de decidir por su cuenta qué campo querías exportar: si se equivoca adivinando, puede que nunca lo notes. Lo correcto es sacar el array que quieres exportar y pegar eso. Igual: los arrays que mezclan números o cadenas, o cuyos elementos no son objetos, se rechazan explicando el porqué.
Eso es la inferencia automática de tipos de Excel, no un defecto del CSV: un número de 18 dígitos pasa a 1.2E+17, y textos como 2024-01-05 se leen como fecha. La especificación CSV no tiene concepto de «tipo», así que ninguna herramienta puede impedírselo. El arreglo fiable: para números largos que deban quedar exactos (números de pedido, de documento), tras exportar marca en Excel esa columna como «Texto» y vuelve a importar (o usa Datos - Desde Texto/CSV y designa la columna como texto en el asistente). El BOM UTF-8 que esta página añade por defecto solo arregla el mojibake del chino: para la inferencia de tipos no hace nada.