Formatear JSON

Formatear aquí significa leer el documento entero y volver a escribirlo. La alternativa barata — ir metiendo saltos de línea y espacios donde aparece una llave — funciona hasta que una cadena contiene una llave, y entonces destroza el documento de una forma que sigue pareciendo JSON.

La consecuencia útil es que el formateo también es una comprobación. Si sale algo, el documento era válido; si no, no lo era, y para eso está la página de validación, que te dice en qué línea se atasca. Un formateador que nunca falla es un formateador que no está leyendo lo que le das.

Dos espacios es lo que escribe `JSON.stringify` cuando se le pide sangrado y lo que usan por defecto casi todas las herramientas de JavaScript. Cuatro viene del mundo de Python y de Java. El tabulador ahorra bytes y deja que cada cual elija la anchura en su editor.

Ninguna de las tres cambia el documento: para un analizador, el espacio en blanco entre elementos no existe. Importa solo si el resultado va a un repositorio, donde una mezcla de convenciones produce diferencias en líneas que nadie tocó — el motivo por el que conviene fijar una y que la fije la herramienta y no la persona.

Un objeto JSON no tiene orden definido, así que dos servicios pueden devolver los mismos datos con las claves en distinta posición. Ordenarlas alfabéticamente convierte una comparación de textos en una comparación útil, que es justo lo que hace falta antes de un diff o de un test de contrato.

Un array es lo contrario: su orden es parte del dato. Aquí no se toca nunca, y esa asimetría es deliberada. Una herramienta que ordenase también los arrays produciría documentos que se comparan bien y significan otra cosa, que es la peor combinación posible.

JSON escribe los números como texto y JavaScript los lee como coma flotante de doble precisión. Los enteros por encima de 9.007.199.254.740.991 pierden cifras: un identificador de 19 dígitos vuelve distinto, y como el resultado sigue pareciendo un número válido no lo nota nadie.

Afecta a cualquier procesamiento que pase por un analizador de JavaScript, este incluido, y se avisa cuando ocurre. El disparador habitual son los identificadores tipo snowflake de Twitter y Discord y algunas secuencias de base de datos. La solución está en quien los genera: esos valores deben ir como cadena, y entonces atraviesan cualquier etapa sin cambiar.

No hay comentarios, no hay comas finales, no hay comillas simples y no hay claves sin comillas. Cada una de esas cosas es una costumbre traída de JavaScript, y cada una deja al analizador parado con un mensaje que casi nunca señala el sitio correcto.

Quien necesite comentarios en una configuración tiene tres salidas: usar un formato que los admita — YAML, TOML, JSON5 —, meter un campo `_comment` que se ignore a propósito, o quitarlos antes de procesar. La tercera es la más extendida y la más frágil, porque una barra doble también aparece dentro de una URL.

El resultado sale en UTF-8 tal cual, sin convertir los caracteres no ASCII en secuencias de escape `\uXXXX`. Ambas formas son JSON válido y significan lo mismo, pero la primera se lee y la segunda no: un nombre con eñe escrito como `\u00f1` es correcto y es ilegible.

Algunas bibliotecas escapan por defecto porque asumen que el transporte no es limpio, lo cual dejó de ser cierto hace tiempo. Si tus datos llegan con esas secuencias, este formateador no las convierte de vuelta — son parte del documento tal y como lo recibiste, y cambiarlas sería reescribir el dato y no su presentación.

Esta página resuelve un problema de lectura: hay un documento delante y no se ve su forma. Es lo que hace falta cuando llega una respuesta de API en una línea, cuando un campo de registro lleva JSON dentro o cuando alguien pega un blob de configuración en un ticket.

No resuelve el problema contrario. Para dejarlo en una línea está la página de minificar, y para averiguar por qué algo lo rechaza está la de validar, que da la línea y la columna. Las tres comparten motor y están separadas porque son tres momentos distintos con tres preguntas distintas.

Un JSON minificado dentro de un fichero versionado convierte cualquier cambio en una línea modificada. El diff pasa a ser todo o nada, la revisión se vuelve imposible y un conflicto de fusión afecta al documento entero en lugar de a los dos campos de los que iba.

El reparto que funciona es el evidente: formateado en el repositorio, minificado al servir. Entre los dos estados está exactamente el paso que un proceso de compilación debería dar solo, y ninguna de las dos formas es la correcta en abstracto — lo son en su sitio.

Un payload JSON contiene con frecuencia justo lo que no conviene mover: registros de clientes, datos de pedidos, un webhook con direcciones dentro. Como aquí se analiza y se reescribe en la propia página, no hay comunicación a nosotros y por tanto tampoco encargo de tratamiento sobre ese contenido.

Se demuestra en el panel de red: mientras la usas no sale ninguna petición que lleve tu documento. Es la razón por la que esta herramienta se puede usar donde una versión con servidor chocaría con una política interna, y comprobarlo cuesta un minuto.