Para qué sirve
JSON es el formato en el que hablan casi todas las APIs, y también el de media docena de ficheros de configuración que tocas cada semana. El problema es que viaja minificado —sin saltos de línea ni espacios— y así no hay quien lo lea. Esta herramienta hace las dos cosas que necesitas al pegar uno: decirte si es válido y, si lo es, devolvértelo con la sangría que le pidas.
Cuando no es válido, lo importante no es el «no» sino el dónde. Aquí el error viene con la línea y la columna exactas, con el fragmento de texto señalado debajo y con una explicación de qué falla: una coma final, unas comillas simples, un comentario que ese fichero no admite. Eso es lo que convierte diez minutos de contar llaves en diez segundos.
Todo ocurre dentro de tu navegador. El texto que pegas no sale de tu ordenador: no hay ninguna petición al servidor, ni antes ni después de procesarlo. Puedes comprobarlo abriendo la pestaña «Red» de las herramientas de desarrollo, o directamente desconectando internet y viendo que la herramienta sigue funcionando. Lo que no hace es validar contra un esquema —eso es JSON Schema— ni consultar o transformar el contenido —eso es jq—: aquí se valida, se ordena y se formatea.
Cómo se calcula
El juez es JSON.parse, la función que trae el propio navegador. Si acepta el texto, es JSON válido por definición; si lo rechaza, no lo es. No se usa eval ni new Function en ningún punto, porque ambas ejecutarían lo que hubiera dentro del texto pegado, y aquí el texto viene de fuera.
El resultado no se obtiene retocando el original, sino reconstruyéndolo: se convierte el texto en una estructura de datos y se vuelve a escribir desde cero con la sangría elegida. Por eso la salida siempre es canónica —mismo tipo de comillas, mismo espaciado— y por eso también desaparecen cosas por el camino: las claves duplicadas se quedan en la última, los números se normalizan y cualquier comentario que hubiera hecho fallar el análisis ya no está.
Para localizar un error se aprovecha el mensaje que lanza el motor, con el inconveniente de que cada uno escribe el suyo: Chrome dice «at position 42», Firefox «at line 3 column 5» y Safari a veces no dice nada. Se extrae la posición como se pueda y, si solo hay un índice de carácter, se cuentan los saltos de línea que lo preceden para traducirlo a línea y columna. Después se recorre el texto por fuera de las cadenas buscando a los sospechosos habituales —una coma antes de un cierre, un apóstrofo, una barra doble— para poder nombrar el error en lugar de limitarse a señalarlo.
salida = JSON.stringify(JSON.parse(texto), null, sangría)- JSON.parse
- lee el texto y devuelve la estructura, o lanza un error. No ejecuta nada
- null
- el hueco del «replacer»: aquí no se filtra ni se transforma ninguna clave
- sangría
- dos espacios, cuatro espacios, un tabulador, o cadena vacía para minificar
Formatear y minificar son la misma operación con distinto tercer argumento.
línea = saltos de línea antes de la posición + 1
columna = posición − índice de inicio de esa línea + 1- posición
- índice del carácter donde el motor abandonó el análisis, empezando en 0
Ambas empiezan a contar en 1, que es como numeran las líneas todos los editores.
Ejemplo resuelto
Una respuesta de API pegada tal cual
- Texto pegado
- {"usuario":{"id":42,"nombre":"Lucía","roles":["editor","revisor"],"activo":true,"baja":null}}
- Sangría
- 2 espacios
- El texto ocupa 94 bytes en una sola línea: es válido, pero ilegible.
- JSON.parse lo acepta, así que se marca como válido y se vuelve a escribir con dos espacios por nivel: salen 12 líneas y 151 bytes.
- Se recorre la estructura para contar las claves: usuario, id, nombre, roles, activo y baja. Son 6.
- Y los valores hoja, que son los que ya no contienen nada dentro: 42, «Lucía», «editor», «revisor», true y null. También 6.
- La profundidad es 3: el objeto raíz es el nivel 1, el objeto usuario el 2 y el array roles el 3.
JSON válido · 6 claves · 6 valores · profundidad 3 · 12 líneas · 151 bytes. Formatear ha añadido 57 bytes de espacios en blanco; minificarlo de vuelta los quita.
Lo que JSON no admite y JavaScript sí
Casi todos los errores de sintaxis salen de escribir JSON como si fuera un objeto de JavaScript. Se parecen, pero JSON es mucho más estricto: no tiene comentarios, no perdona una coma de más y solo reconoce un tipo de comilla. Esta es la lista de lo que se cuela.
Cuando el error no aparece por ninguna parte y el texto «se ve bien», casi siempre hay algo invisible de por medio: una marca BOM al principio del fichero, o unas comillas tipográficas que un procesador de textos ha puesto en lugar de las rectas. Las dos cosas las detecta esta herramienta y las nombra.
| No válido en JSON | Cómo se escribe |
|---|---|
| {"a": 1,} | {"a": 1} — sin coma final |
| {'a': 1} | {"a": 1} — comillas dobles siempre |
| {a: 1} | {"a": 1} — la clave también va entrecomillada |
| // un comentario | Bórralo, o guárdalo dentro de una clave "_nota" |
| {"a": NaN} | {"a": null} o {"a": "NaN"} |
| {"a": undefined} | {"a": null}, o quita la clave entera |
| {"cp": 08001} | {"cp": "08001"} — ningún número empieza por cero |
| {"a": .5} | {"a": 0.5} — y {"a": +5} se escribe {"a": 5} |
| Un salto de línea dentro de un texto | Escríbelo como \n |
JSON, JSONC y JSON5 no son lo mismo
Si pegas aquí un tsconfig.json con comentarios, la herramienta va a protestar, y hace bien: ese fichero no es JSON, es JSONC. Es una extensión que admite comentarios y comas finales, y que entienden VS Code y el compilador de TypeScript, pero no JSON.parse ni la mayoría de librerías de otros lenguajes.
JSON5 va más allá y se parece ya del todo a JavaScript. Ninguna de las dos es intercambiable con JSON: sirven para ficheros de configuración que edita una persona, nunca para lo que viaja por una API. Esta herramienta valida JSON estricto, el que define el RFC 8259.
| Característica | JSON | JSONC | JSON5 |
|---|---|---|---|
| Comentarios | No | Sí | Sí |
| Coma final | No | Sí | Sí |
| Comillas simples | No | No | Sí |
| Claves sin comillas | No | No | Sí |
| NaN e Infinity | No | No | Sí |
| Dónde se usa | APIs y datos | tsconfig, VS Code | Configuración a mano |
Preguntas frecuentes
¿Se envía mi JSON a algún servidor?
No. El análisis lo hace JSON.parse en tu navegador, con código que ya está descargado; no se dispara ninguna petición de red con el contenido. Si trabajas con datos de clientes y necesitas asegurarte, abre las herramientas de desarrollo en la pestaña «Red» y comprueba que no ocurre nada al pegar, o corta la conexión y verás que la herramienta sigue funcionando igual.
El JSON se ve bien y aun así dice que hay un error. ¿Qué miro?
Casi siempre es algo que no se ve. Los tres sospechosos, por orden de frecuencia: una coma final antes de un cierre de llave o de corchete, unas comillas tipográficas que ha metido Word, Notion o Slack al copiar, y una marca BOM invisible al principio del fichero. Fíjate en el fragmento con el circunflejo debajo: señala el carácter exacto donde el análisis se detuvo, que suele estar justo después del problema real.
¿Se pierde algo al formatear?
Sí, y conviene saberlo. Las claves duplicadas se colapsan en la última: de {"a":1,"a":2} sale {"a":2}. Los números se normalizan, así que 1.0 pasa a 1 y 1e3 a 1000, y las secuencias de escape como \u00f1 se convierten en el carácter que representan. Y lo más peligroso: los enteros de más de 16 cifras pierden precisión, porque JavaScript los guarda como decimales de doble precisión. Un identificador como 9007199254740993 sale como 9007199254740992. Si manejas IDs largos de Twitter, Snowflake o similares, usa la salida para leer, no como sustituto del original.
¿Cuándo merece la pena minificar?
Cuando el JSON va a viajar sin comprimir o va incrustado dentro de otra cosa: un atributo de HTML, una variable de entorno, un campo de base de datos, un mensaje en una cola. En una respuesta HTTP normal el ahorro es casi irrelevante, porque gzip o brotli ya eliminan los espacios repetidos con muchísima más eficacia. Lo que no deberías hacer nunca es minificar un fichero que va a git: pierdes la posibilidad de ver un diff línea a línea.
¿Para qué sirve ordenar las claves alfabéticamente?
Para comparar dos respuestas. El orden de las claves de un objeto no significa nada en JSON: {"a":1,"b":2} y {"b":2,"a":1} son exactamente el mismo dato. Pero cualquier herramienta de diff los ve como texto distinto y te llena la pantalla de diferencias falsas. Si ordenas las dos respuestas con el mismo criterio y luego las comparas, solo queda lo que ha cambiado de verdad. Los arrays se dejan como están, porque ahí el orden sí forma parte del dato.
¿Dos espacios, cuatro o tabulador?
Dos espacios es lo que usan Prettier y npm por defecto, y es lo que menos desplaza el texto en estructuras muy anidadas. Cuatro se lee algo mejor en ficheros planos y poco profundos. El tabulador tiene una ventaja real que suele olvidarse: cada persona configura en su editor cuánto ocupa, lo que ayuda a quien necesita una sangría más ancha por accesibilidad. Si el fichero entra en un repositorio, lo único que importa de verdad es que sea siempre el mismo.
¿Hay un límite de tamaño?
500.000 caracteres, alrededor de 500 KB. Por encima de eso la herramienta deja de procesar y te avisa, en lugar de bloquear la pestaña analizando el texto entero en cada tecla que pulsas. Además, del resultado solo se pintan los primeros 200.000 caracteres para que la página siga respondiendo; el botón de copiar sí entrega el resultado completo. Si trabajas con ficheros más grandes, jq desde la terminal es la herramienta adecuada.
Ten en cuenta
Fuentes
Toda la información de esta página se refiere a: JSON Formatter y validador.