Formatear y validar JSON son tareas relacionadas, pero responden preguntas distintas. El formateo cambia espacios y saltos de línea para que un payload resulte legible. La validación sintáctica comprueba si el texto cumple la gramática JSON. La validación mediante un schema o reglas de aplicación determina si el valor ya parseado tiene los campos, tipos y restricciones que un sistema espera. Por eso un documento puede verse ordenado y seguir siendo inválido, o parsearse sin errores y no servir para una API.

Un flujo fiable separa esas etapas. Conserva la entrada original, ejecútala en un parser estricto, utiliza la posición del error para corregir la sintaxis, formatea el resultado válido y compara después su estructura con el contrato. Esta guía explica el proceso y los fallos que aparecen con más frecuencia.

Qué permite realmente un JSON válido

JSON utiliza un vocabulario pequeño: objetos, arrays, strings, números, los literales true y false, y null. Los nombres de propiedades y los strings llevan comillas dobles. Las comas separan miembros o elementos, mientras los dos puntos separan cada nombre de su valor. El whitespace alrededor de los caracteres estructurales no modifica los datos.

El estándar formal, RFC 8259, permite cualquier valor JSON en el nivel superior, aunque objetos y arrays suelen ofrecer mejor interoperabilidad. No permite comentarios, comas finales, strings con comillas simples, NaN ni Infinity. Esas construcciones pueden funcionar en JavaScript o en un parser tolerante de configuración, pero no pertenecen a JSON estricto.

Formatear no significa reparar

Un formateador JSON, también llamado pretty printer, normalmente parsea la entrada y vuelve a serializarla con una indentación y unos saltos de línea consistentes. Minificar realiza el cambio visual inverso y elimina el whitespace insignificante. Ninguna operación debería inventar una comilla, borrar una coma sobrante o adivinar el significado de un valor mal formado. Las reparaciones silenciosas ocultan si el documento aún representa la intención del productor.

Cuando el formateador rechaza la entrada, considera ese fallo una pista útil. Guarda una copia intacta, anota el carácter o la línea indicada y revisa la estructura próxima. Una vez corregida la sintaxis, la indentación revela objetos y arrays anidados, algo especialmente útil al revisar respuestas de API, webhooks, logs o archivos de configuración.

Errores comunes de sintaxis JSON

Las comas finales son un fallo habitual: {"active": true,} no es válido. También fallan las comillas simples, las comillas dobles sin escapar dentro de un string, las comas ausentes entre miembros y los saltos de línea literales dentro de texto entrecomillado. Los nombres de propiedades deben llevar comillas incluso si serían identificadores válidos en JavaScript. Los literales usan minúsculas, de modo que True, NULL y undefined son incorrectos.

La posición del parser suele señalar el lugar donde ya no pudo continuar, no necesariamente donde nació el error. “Final inesperado” puede indicar que antes quedó abierto un objeto, array o string. Un error junto al nombre de una propiedad puede deberse a una coma ausente en la línea anterior. Revisa desde el punto indicado y empareja llaves, corchetes, comillas y separadores.

Un flujo práctico de validación

Empieza con los bytes exactos recibidos. Si los datos llegaron por HTTP, comprueba el status code y el Content-Type antes de asumir que el body es JSON; las páginas de login y los errores del proxy suelen ser HTML. Después pega una muestra segura, sin secretos, en un validador JSON estricto o ejecuta el parser de tu plataforma. En JavaScript, JSON.parse() devuelve el valor representado y lanza SyntaxError si la entrada es inválida.

Corrige un problema cada vez, porque el primer fallo estructural puede generar varios síntomas engañosos. Cuando el parseo funcione, aplica una indentación de dos o cuatro espacios, inspecciona los niveles y contrasta el resultado con la documentación o el schema. Finalmente, guarda el payload corregido como fixture de una prueba para evitar que el mismo caso límite reaparezca.

La sintaxis válida no garantiza datos correctos

El documento {"email": 42} es JSON válido, pero una API de cuentas probablemente espera que el email sea string. Un timestamp puede ser un string válido y tener un formato equivocado. Puede faltar una propiedad obligatoria, aparecer un enum desconocido o superar un array el límite aceptado. Son errores de contrato, no de gramática JSON.

Usa JSON Schema, validación OpenAPI o reglas de aplicación para esta segunda capa. Define propiedades obligatorias y opcionales, tipos, formatos, rangos y si se permiten campos adicionales. Los mensajes de error deben diferenciar JSON mal formado de un payload bien formado que incumple el contrato, porque quien integra la API necesita una solución distinta en cada caso.

Números, Unicode y claves duplicadas

Una sintaxis correcta aún puede esconder problemas de interoperabilidad. JSON define números sin imponer una representación idéntica en todos los runtimes. Los identificadores enteros grandes pueden perder precisión en entornos basados en IEEE 754 binary64, así que suele ser más seguro transportar IDs opacos como strings. Los importes exactos también necesitan una representación acordada.

El JSON intercambiado entre sistemas abiertos debe usar UTF-8. Unicode escapado y sin escapar puede representar los mismos caracteres, detalle importante al comparar bytes o firmar un documento. Las propiedades duplicadas son otra trampa: un parser puede conservar el primer valor, el último o devolver un error. Los productores deben emitir nombres únicos y los consumidores sensibles a seguridad deberían rechazar entradas ambiguas.

Cómo formatear JSON sin filtrar secretos

Antes de usar un formateador externo, busca access tokens, contraseñas, datos personales, claves privadas, cookies de sesión o URLs internas. Prefiere una herramienta que se ejecute localmente en el navegador y no suba la entrada. En incidentes de producción, crea una muestra reducida y sustituye los valores sensibles conservando la estructura que reproduce el problema.

No pegues una credencial activa solo porque el documento sea difícil de leer. La redacción debe ocurrir antes de compartir o registrar el payload e incluir campos anidados, no únicamente nombres obvios del primer nivel. Si una prueba depende de determinada longitud o patrón, utiliza un valor sintético equivalente.

Formatea para personas y valida para sistemas

La regla más útil es breve: primero parsea, después formatea y por último valida el contrato. Una indentación clara ayuda a comprender un payload, pero solo un parser estricto demuestra que es JSON y solo un schema o una regla de aplicación confirma que pertenece a ese flujo.

Usa el formateador y validador JSON para hacer visibles los errores sintácticos; luego revisa por separado tipos, campos obligatorios, precisión numérica, encoding y seguridad. Este enfoque convierte un mensaje opaco del parser en un proceso repetible y evita confundir “JSON válido” con “datos correctos”.