Formateador JSON

Acerca de Formateador JSON

Esta herramienta lee lo que pegas con el JSON.parse integrado en el navegador y lo vuelve a escribir con JSON.stringify. El resultado no es, por tanto, una copia ordenada de tu texto, sino una serialización nueva del valor que entendió el motor. Por eso 0.1000 sale como 0.1, 1E3 como 1000 y \u00e9 como é.

La gramática de JSON es mínima, pero el texto escrito a mano o copiado de un literal de objeto de JavaScript arrastra con facilidad sintaxis fuera del estándar. A continuación se explica qué permiten de verdad las especificaciones (RFC 8259 y ECMA-404), dónde se suele fallar y en qué casos el análisis cambia los datos sin avisar.

Sintaxis habitual que la especificación rechaza

Según el RFC 8259, un texto JSON es un único valor cualquiera. Las especificaciones antiguas exigían que el nivel superior fuera un objeto o un array; hoy un simple "hello", 42 o null es JSON válido, y esta herramienta lo acepta. En cambio, todo lo de la lista siguiente produce error.

• Comas finales: {"a": 1,} y [1,2,3,]
• Cadenas con comillas simples y claves sin comillas: {'a': 1}, {a: 1}
• Comentarios de cualquier tipo, // o /* */
• NaN, Infinity y -Infinity. El RFC indica que no se permiten los valores numéricos que no pueden representarse con la gramática, como Infinity y NaN. En sentido contrario, JSON.stringify({x: NaN}) en JavaScript devuelve {"x":null} sin ningún aviso: el valor desaparece.
• Ceros a la izquierda: 01 falla; 0.5 es válido, pero .5 no.
• Solo cuatro caracteres cuentan como espacio en blanco: espacio, tabulador, salto de línea y retorno de carro. La marca de orden de bytes (BOM, U+FEFF) al inicio de un archivo no es uno de ellos, así que JSON.parse falla en el primer carácter. El RFC 8259 establece que las implementaciones NO DEBEN (MUST NOT) añadir BOM al JSON transmitido por red. Si un archivo guardado como «UTF-8 con BOM» da error en la posición 0, esa es la causa.

Los archivos que admiten comentarios no son JSON

VS Code abre settings.json, tasks.json y launch.json en modo «JSON with Comments» (jsonc): ahí funcionan los comentarios // y /* */, y las comas finales solo generan una advertencia. JSON5 es otro formato que va más allá y admite comillas simples, claves sin comillas e Infinity. Si pegas uno de estos archivos aquí y aparece un error, es lo esperado: quita antes los comentarios y las comas finales, o usa un analizador hecho para ese formato.

Tres formas en que el análisis altera los datos

Claves duplicadas. La especificación solo dice que los nombres DEBERÍAN (SHOULD) ser únicos y que, si no lo son, «el comportamiento del software que recibe ese objeto es impredecible». JavaScript se queda con el último, así que {"a":1,"a":2} se formatea como {"a": 2} y el primer valor se pierde. Los analizadores de otros lenguajes pueden conservar el primero o rechazar el documento.

Enteros grandes. Los números de JavaScript son dobles IEEE 754, y el RFC 8259 señala que solo los enteros entre -(2^53-1) y 2^53-1 (9007199254740991) son interoperables, en el sentido de que todas las implementaciones coinciden exactamente en su valor. Un identificador de 64 bits por encima de ese límite pierde sus últimas cifras. Por eso la API de Twitter (hoy X) enviaba cada ID de tuit dos veces, como número en id y como cadena en id_str, y su documentación pedía usar id_str al consumir JSON. JSON.parse redondea esos valores sin dar error, así que esta herramienta busca en la entrada enteros mayores que 2^53 y muestra un aviso junto al resultado.

Orden de las claves. Aunque la ordenación esté desactivada, las claves con forma de entero, como "2" o "10", pasan al principio en orden numérico ascendente, porque así enumera JavaScript las propiedades de un objeto. Con la ordenación activada, la herramienta escribe la salida sin depender del orden del objeto, así que todas las claves —también las de forma de entero— se ordenan por código de carácter: mayúsculas antes que minúsculas y "10" antes que "2". El orden dentro de los arrays nunca se toca.

Cómo leer el mensaje de error

El mensaje es el texto en inglés que genera el propio motor. Las versiones recientes de Chrome y Edge (V8) escriben cosas como «Expected ',' or '}' after property value in JSON at position 23 (line 4 column 3)». Firefox usa la forma «JSON.parse: expected ',' or '}' after property value in object at line 4 column 3 of the JSON data». La herramienta busca «line L column C» o «position N» en el texto y lo convierte en línea y columna. Algunos mensajes no incluyen posición, por ejemplo el de V8 «Unexpected token ']', "[1,2,3,]" is not valid JSON», y entonces no se muestra ubicación.

La posición indicada es donde el analizador ya no pudo seguir, no donde está el error humano. Si falta una coma al final de la línea 3, el error señala la clave de la línea 4. Revisa primero lo que hay justo antes del punto marcado.

¿Cuánto ahorra minimizar?

Lo medimos con un array de 1.000 objetos de tres campos (id, name, active), usando zlib de Node.js con la configuración por defecto: con sangría de 2 espacios ocupa 67.282 bytes y minimizado 43.281 bytes, un 36 % menos en bruto. Tras gzip quedan en 5.371 y 5.106 bytes, apenas un 5 % de diferencia; con Brotli, 2.493 y 2.245 bytes. Si tu servidor ya comprime las respuestas, quitar espacios aporta poco. Importa más para el almacenamiento, en rutas sin compresión de transferencia o cuando el JSON debe caber en una sola línea de log.

Ejemplos

Cómo se usa

1. Pega el JSON en el cuadro de entrada.
2. Elige la sangría (2 espacios, 4 espacios o tabulación) y si quieres ordenar las claves.
3. Pulsa Formatear o Minimizar. Si hay error, revisa el texto justo antes de la línea y columna indicadas.

Preguntas frecuentes