Cómo corregir el error de token inesperado en JSON

El error de token inesperado aparece cuando el analizador, mientras lee el JSON carácter a carácter, se topa con algo que no esperaba en ese punto de la estructura. Un token es simplemente una pieza del texto con significado: una llave, un corchete, una coma, dos puntos, una comilla, un número o una palabra clave como true. El analizador sigue una gramática que le dice qué tokens pueden aparecer en cada momento. Cuando el siguiente carácter no es ninguno de los válidos allí, lanza el error y se detiene. Por eso el mensaje suele incluir el carácter concreto y una posición. Entender que el problema es de sintaxis, y no del contenido de los datos, es el primer paso para resolverlo con rapidez en lugar de dar palos de ciego.

Las causas de un token inesperado son casi siempre las mismas. La más común es una coma final: tras la coma el analizador espera otro elemento y encuentra una llave o un corchete de cierre, que interpreta como inesperado. Le siguen las comillas: usar comillas simples en lugar de dobles, dejar una cadena sin cerrar o colar comillas tipográficas al copiar y pegar. También lo provocan los valores sin comillas, como una cadena escrita sin entrecomillar, y las llaves o corchetes descolocados o de más. A veces es un carácter perdido, un fragmento pegado dos veces o texto ajeno al JSON, como una etiqueta HTML de una página de error que se coló en una respuesta que debía ser JSON. Reconocer estos patrones acelera mucho el diagnóstico una vez que sabe dónde mirar.

Aquí es donde el validador resulta más valioso. En lugar de un mensaje abstracto, le da una posición concreta: la línea y la columna donde el análisis se detuvo. Ese es el token que la especificación no admite en ese lugar. Un detalle importante es que el carácter señalado no siempre es el que está mal, sino el primero que revela el problema. Con una coma final, por ejemplo, el token inesperado que se marca es el cierre que viene después, aunque la corrección esté en la coma anterior. Por eso conviene mirar también el carácter inmediatamente previo a la posición indicada. Tener la línea y la columna delante convierte una búsqueda a ciegas por todo el documento en una inspección de unos pocos caracteres, que es lo que marca la diferencia en archivos grandes.

Para corregirlo, vaya a la posición señalada y decida qué falta o qué sobra. Si hay una coma antes de un cierre, bórrela. Si ve comillas simples, cámbielas por dobles; si una cadena no se cierra, añada la comilla que falta. Si un valor de texto aparece sin comillas, enciérrelo entre comillas dobles. Si sobra o falta una llave o un corchete, ajuste la pareja para que cada apertura tenga su cierre. Recuerde que el analizador informa de un solo error por pasada, el primero que encuentra. Después de arreglarlo y volver a validar puede surgir otro más adelante, lo cual es normal y no significa que su primera corrección estuviera mal. Trabajando de arriba abajo, validando y corrigiendo, irá resolviendo los tokens inesperados uno tras otro hasta que el documento sea válido.

Conviene subrayar que toda esta comprobación se hace de forma local en su navegador. El JSON que pega para cazar el token inesperado no se sube a ningún servidor ni se almacena, de modo que puede analizar respuestas de API reales o archivos de configuración internos sin exponerlos. Para prevenir estos errores, ayuda editar el JSON con un editor que resalte la sintaxis y equilibre automáticamente las comillas y los paréntesis, y formatear el documento con indentación clara para que un carácter fuera de lugar salte a la vista. Cuando el JSON procede de una respuesta de red, verifique que realmente es JSON y no una página de error o un mensaje en texto plano, ya que ese contenido inesperado es una causa habitual del problema. Una validación rápida antes de procesar el dato le ahorra sorpresas.