Formateador JSON

Qué acepta este formateador

El parser sigue la RFC 8259 al pie de la letra, lo que es más estricto de lo que la mayoría espera. Las claves deben ir entre comillas dobles. Las cadenas usan comillas dobles, nunca simples. No hay coma tras el último elemento de un objeto o array, no existe ninguna sintaxis de comentarios y no hay NaN, Infinity ni undefined. Los números no pueden escribirse en hexadecimal, no pueden llevar un signo más delante ni un cero inicial en la parte entera.

Ese rigor es deliberado, no quisquilloso: es lo que aplicará cualquier parser JSON en el lado receptor. Un documento que se formatea aquí se podrá leer en Python, Go, Rust y PostgreSQL. Un documento que solo funciona después de que un parser tolerante adivine tu intención fallará más adelante en algún sitio, normalmente en producción.

Si tu entrada tiene comentarios o comas finales, no es JSON sino JSON5 o JSONC, las variantes relajadas que usan archivos de configuración como tsconfig.json. Son formatos reales con usos reales, y quitar los comentarios para que el documento sea JSON válido es una edición con pérdida. Hazlo sabiéndolo.

Cómo leer el error

Cuando el análisis falla, el error incluye línea y columna, calculadas a partir de la posición de carácter que informa el motor. Ten en cuenta que esa posición es donde el parser se rindió, no siempre donde cometiste el error: una llave de cierre que falta suele notificarse al final del documento, porque todo hasta ese punto aún podía ser válido.

Las cuatro causas que explican casi todos los fallos son una coma antes de un corchete o llave de cierre, comillas simples alrededor de una cadena o clave, una clave sin comillas copiada de un literal de objeto de JavaScript y una comilla doble o un salto de línea sin escapar dentro de un valor de cadena. Si la columna indicada apunta a unas comillas, probablemente la cadena anterior terminó antes de tiempo.

El otro caso habitual son los documentos truncados. Una respuesta cortada por un límite de tamaño o un timeout se analiza sin problemas hasta que se detiene a mitad de un valor, así que el error aparece en la última línea y no en un lugar que ayude. Revisa el final de la entrada antes de buscar por el medio.

Qué cambia al analizar y volver a escribir

Formatear analiza el documento y lo vuelve a serializar, así que algunas cosas se normalizan por el camino, y conviene saber cuáles.

Los números pasan a ser dobles IEEE 754. Cualquier entero mayor que 9.007.199.254.740.991 pierde precisión, y eso importa porque los ID de base de datos de 64 bits, los ID snowflake al estilo de Twitter y las marcas de tiempo en nanosegundos están todos por encima de ese límite. Un ID 9223372036854775807 vuelve como 9223372036854776000. Si necesitas conservarlos intactos, mantenlos como cadenas en el payload. Los ceros finales también desaparecen: 1.0 se formatea como 1 y 1e3 como 1000.

Las claves duplicadas se fusionan y gana la última, porque el paso de análisis construye un objeto. Por lo demás se conserva el orden de las claves, con una excepción heredada de los objetos de JavaScript: las claves que parecen enteros no negativos se ordenan numéricamente y pasan delante del resto. Los comentarios y los espacios originales desaparecen por definición, ya que ninguno sobrevive al análisis.

La vista de árbol

Encima del texto formateado hay un árbol plegable. Sirve para otra tarea: descubrir la forma de una respuesta desconocida, dónde está el campo que te interesa y a qué profundidad está anidado, sin desplazarte por miles de líneas indentadas. Pliega los arrays que no te importan y la estructura cabe en una pantalla.

El botón de copiar entrega siempre el texto formateado, así que explorar en el árbol nunca cambia lo que pegas de vuelta en tu editor.

De dónde salió JSON y qué puede contener

JSON fue especificado por Douglas Crockford a principios de los años 2000 como un subconjunto de la sintaxis de objetos literales de JavaScript, a partir de la observación de que los navegadores ya podían interpretarla y de que XML era más pesado de lo que la mayoría de las API web necesitaba. Se estandarizó como RFC 4627 y más tarde fue reemplazado por RFC 8259 y ECMA-404, y el hecho de que su gramática quepa en una sola página explica casi todo su éxito.

El modelo de datos es deliberadamente pequeño: objetos, arreglos, cadenas, números, booleanos y null. Eso es todo. No hay tipo fecha, no hay tipo binario, no hay distinción entre entero y coma flotante, no hay comentarios y no hay forma de expresar una referencia desde una parte del documento hacia otra.

Todo lo incómodo de JSON se desprende de esa lista. Las fechas tienen que ser una convención en lugar de un tipo, lo binario hay que codificarlo como texto, los enteros grandes tensionan un formato cuyos números suelen interpretarse como doubles, y los archivos de configuración - que piden comentarios - terminan usando un dialecto o directamente otro formato.

Fechas, dinero y números grandes

Para las fechas, la convención asentada es ISO 8601 en UTC, como en 2026-03-14T09:30:00Z. Se ordena lexicográficamente, no es ambigua y cualquier lenguaje puede interpretarla. Las alternativas traen problemas: una marca de tiempo Unix pierde la distinción entre segundos y milisegundos, y una cadena localizada como 03/14/2026 es ambigua fuera del país que la escribió.

El dinero no debería ser un número JSON. Los parsers pueden usar coma flotante de doble precisión, así que los problemas del estilo 0.1 más 0.2 llegan junto con el payload, y el redondeo se comporta distinto según el lenguaje. Unidades menores en entero - 1999 para £19.99 - con la moneda en un campo aparte es la representación que sobrevive a cualquier consumidor.

Los identificadores grandes tienen el mismo problema en una forma más aguda. Todo valor por encima de 2^53 pierde precisión al interpretarse como double, lo que incluye ids de base de datos de 64 bits e identificadores tipo snowflake, así que deben viajar en el payload como cadenas. No es hipotético: es la razón por la que varias API grandes devuelven tanto un campo id como un campo id_str.

Archivos demasiado grandes para la memoria

Un parser que construye el documento completo como objeto necesita varias veces el tamaño del archivo en memoria, de modo que una exportación de 500 MB puede agotar un proceso en una máquina con gigabytes libres. Hay dos enfoques que lo evitan.

El primero es JSON delimitado por saltos de línea, donde cada línea es un documento completo y el archivo en conjunto no es JSON válido. Se transmite de forma natural, se le agregan líneas de manera barata y es lo que usan la mayoría de las tuberías de logs y los formatos de exportación masiva. El segundo es un parser de streaming - ijson en Python, un lector estilo SAX en otros lenguajes - que emite eventos mientras recorre el archivo y nunca materializa el árbol completo.

En la línea de comandos, jq maneja ambos casos y vale la pena aprenderlo por sí solo: jq '.items[] | {id, name}' big.json extrae una proyección sin cargar el documento en un editor. Su bandera --stream cubre los casos en que incluso el modo por defecto de jq usaría demasiada memoria.

La superficie de seguridad de un payload JSON

Interpretar JSON es seguro en cualquier lenguaje moderno; los riesgos están en lo que ocurre después. El más conocido es la contaminación de prototipos: en JavaScript, mezclar dentro de un objeto un JSON controlado por un atacante sin filtrarlo puede fijar __proto__ y cambiar el comportamiento de todos los objetos del proceso. Las utilidades de merge profundo han publicado este error una y otra vez, y la defensa es rechazar esas claves de forma explícita o usar un objeto con prototipo nulo.

Nunca evalúes JSON. Usar eval para interpretarlo fue una práctica real en la época anterior a JSON.parse, y eso ejecuta lo que sea que llegue. Cualquier código que hoy recurra a eval sobre datos es un hallazgo de seguridad, no una preferencia de estilo.

Hay dos casos menores que conviene conocer. Servir un arreglo JSON con un content type que el navegador va a ejecutar fue la base de los viejos ataques de JSON hijacking, y por eso algunas API todavía anteponen a sus respuestas una línea que rompe el bucle. Y las claves duplicadas son legales en la gramática pero cada parser las maneja distinto, algo que se ha usado para colar ante un validador un valor diferente del que la aplicación termina leyendo.

Los dialectos y cuándo usar alguno

JSON5 agrega comentarios, comas finales, claves sin comillas y cadenas con comillas simples. JSONC es la variante más pequeña que Visual Studio Code usa para su configuración y para tsconfig.json: en esencia, JSON más comentarios. Ninguno de los dos es JSON, y ninguno se interpretará con una biblioteca estándar sin un paquete dedicado.

La distinción que importa es el público. Un archivo que mantiene una persona gana muchísimo con los comentarios, así que JSON5, JSONC, YAML o TOML son opciones razonables ahí. Un payload que cruza la red debería ser JSON plano, porque el extremo receptor puede ser cualquier lenguaje y cualquier versión de biblioteca, y un dialecto convierte una garantía de interoperabilidad en una dependencia.

Cuando pegas un archivo de configuración en un parser estricto y falla, eso normalmente significa que el archivo es un dialecto y no que esté mal formado. Quitarle los comentarios para contentar al parser es una edición que destruye la documentación de alguien, así que hazlo sobre una copia.