¿Es este JSON válido?

Cuando se pregunta si un JSON es válido, la respuesta definitiva no la da la intuición sino el analizador. Un texto es JSON válido si un analizador conforme a la especificación puede interpretarlo por completo sin detenerse. Por eso el validador es tan útil: reproduce ese análisis y le da un veredicto claro en lugar de una impresión. A simple vista, un JSON puede parecer correcto y aun así fallar por un detalle mínimo, como una coma de más o una comilla que en realidad es tipográfica. La ventaja de comprobarlo es que elimina la conjetura. En lugar de leer y releer buscando el fallo, deja que la máquina recorra el texto carácter a carácter y le señale el primer punto donde la sintaxis deja de cumplirse.

La regla que más sorprende a quien viene de JavaScript es la de las comillas. En JSON, tanto las claves como las cadenas de texto tienen que ir entre comillas dobles. Las comillas simples no son válidas, aunque en JavaScript funcionen sin problema. Tampoco valen las comillas tipográficas o curvas que a veces introducen los editores de texto o los procesadores de documentos al copiar y pegar. Por ejemplo, un objeto que asigna una cadena a la clave nombre debe escribir esa clave y su valor entre comillas dobles rectas. Un solo carácter de comilla equivocado hace que el analizador se detenga y marque el texto como no válido. Este es uno de los motivos más frecuentes por los que un JSON aparentemente correcto resulta rechazado sin que se vea a primera vista.

Otras dos reglas explican la mayoría de los rechazos. La primera es que JSON no admite comas finales: no puede haber una coma después del último elemento de un array ni después del último par de un objeto. Es un hábito habitual, porque muchos lenguajes de programación sí lo toleran, pero en JSON provoca un error. La segunda es que JSON no permite comentarios de ningún tipo, ni con dos barras ni con la combinación de barra y asterisco. Aunque su editor los muestre atenuados, para el analizador son texto inesperado. A esto se suma que cada llave y cada corchete de apertura necesitan su pareja de cierre, correctamente anidada. Si repasa comillas, comas, comentarios y paréntesis, habrá cubierto las causas más comunes de invalidez en un documento JSON.

Conviene recordar también qué puede contener un JSON válido, porque no todo vale como valor. Los valores admitidos son cadenas entre comillas dobles, números, los literales true, false y null, además de objetos y arrays que a su vez contienen más valores de estos tipos. No existen en JSON conceptos como undefined, funciones, fechas nativas ni NaN; si aparecen, el texto deja de ser válido. Los números se escriben sin comillas y no admiten ceros a la izquierda ni un punto sin dígitos alrededor. Un documento JSON completo, en su nivel más alto, suele ser un objeto o un array, aunque un valor simple también es técnicamente válido. Tener presente esta lista de tipos ayuda a distinguir un error de sintaxis de un dato que sencillamente no pertenece a JSON.

Una duda razonable al pegar JSON en una web es qué ocurre con ese contenido. En esta herramienta la respuesta es tranquilizadora: la validación se realiza de forma local en su navegador y el texto no se sube a ningún servidor. Puede comprobar respuestas de API con datos reales o archivos de configuración sin exponerlos. En cuanto al resultado, tenga en cuenta que el analizador señala el primer error que encuentra, con su línea y su columna. No enumera todos los fallos a la vez, así que tras corregir el punto indicado conviene volver a validar, porque puede haber otro más adelante. Repitiendo este ciclo de validar y corregir llegará a la confirmación de que el JSON es, por fin, completamente válido y está listo para usarse.