Formateador y Validador JSON

Por qué JSON sigue en todas partes

JSON (JavaScript Object Notation) fue especificado por Douglas Crockford en 2001 como un subconjunto ligero de los literales de objeto de JavaScript. Veinticinco años después, es el formato de cable por defecto para la inmensa mayoría de las APIs públicas — REST, GraphQL, payloads de WebSocket, archivos de configuración, líneas de log. La simplicidad es la característica: solo seis tipos de valor (cadena, número, booleano, null, objeto, array), sin schema obligatorio, sin framing binario.

Formatos más nuevos como Protocol Buffers, MessagePack y CBOR existen por razones (más pequeños, tipados, más rápidos de parsear). Pero la legibilidad humana de JSON lo mantiene como lingua franca para cualquier cosa que un desarrollador pueda abrir en un editor de texto.

Las reglas estrictas que muerden

La especificación JSON (RFC 8259) es más estricta que la sintaxis JavaScript de la que desciende. Tres reglas dan problemas: (1) las claves DEBEN ser cadenas con comillas dobles — `{name: "x"}` es inválido, se requiere `{"name": "x"}`. (2) Las comas finales no están permitidas: `[1, 2, 3,]` parsea en JavaScript pero no en JSON. (3) Los comentarios no están permitidos en absoluto — ni `//` ni `/* */`.

La mayoría de parsers también rechazan NaN, Infinity y -Infinity (no están en la spec), rechazan caracteres de control sin escapar en cadenas y exigen codificación UTF-8. Algunos parsers «relajados» (JSON5, HJSON, JSONC) los aceptan — pero si envías JSON5 a un consumidor estricto, fallará.

Pretty-print vs minificar: cuándo usar cada uno

JSON formateado (con sangría y saltos de línea) es para humanos — revisiones de código, depuración, archivos de configuración en git. JSON minificado (sin espacios en blanco) es para la red — cada byte cuesta latencia y ancho de banda, y un archivo de configuración típico se reduce un 30–60 % al minificarlo.

Regla práctica: pretty-print en reposo (archivos, logs, herramientas de desarrollo), minificar en tránsito (respuestas API, colas de mensajes). La mayoría de servidores HTTP de producción gzipean JSON de forma transparente, así que los ahorros se acumulan: 1 MB de JSON formateado se gzipa a ~80 KB, los mismos datos minificados se gzipean a ~70 KB. Pequeño porcentaje, pero gratis.

Errores de parseo comunes y cómo arreglarlos

«Unexpected token X at position N» — cuenta hasta la posición N para encontrar el carácter problemático. Casi siempre es uno de estos: una clave sin comillas, una comilla simple, una coma final o una barra invertida sin escapar dentro de una cadena.

«Unexpected end of JSON input» — el archivo se truncó a mitad del parseo. Habitual en subidas de archivos que tocan un límite o en respuestas de red parciales sin verificación de error.

«Duplicate key» — JSON permite claves duplicadas por la spec, pero la mayoría de parsers avisa o se queda silenciosamente con la última. No escribas JSON con claves duplicadas; el comportamiento depende de la implementación.

Más allá del formato: validación y schema

Validación aquí significa «¿la sintaxis es JSON legal?» — un control sintáctico. Para validación semántica («¿este objeto tiene los campos que espera mi API?»), usa JSON Schema (borrador RFC) con un validador como Ajv (JavaScript) o jsonschema (Python). JSON Schema permite declarar tipos, campos obligatorios, rangos de valor, patrones regex para cadenas y referencias entre schemas.

En APIs de producción, valida en la frontera. Una payload mala debe fallar rápido con un 400 y un mensaje de error claro — no corromper silenciosamente el estado posterior. JSON Schema genera esos errores automáticamente y es portable entre lenguajes.