Cómo corregir una coma final en JSON

Una coma final, o trailing comma, es la que aparece detrás del último elemento de una lista, justo antes del cierre. En un array sería una coma después del último valor y antes del corchete de cierre; en un objeto, una coma después del último par clave y valor y antes de la llave de cierre. En la mayoría de los lenguajes de programación esta coma es inofensiva e incluso recomendable, porque facilita reordenar líneas y produce diferencias más limpias en el control de versiones. JSON, sin embargo, sigue una gramática deliberadamente estricta y minimalista que no la contempla. Para el analizador, tras esa coma debería venir otro elemento, y al encontrarse con un cierre interpreta que el documento está mal formado. Por eso una sola coma de más invalida el archivo entero.

Este error es tan frecuente precisamente porque muchos entornos sí toleran la coma final. JavaScript moderno la acepta en objetos y arrays, y lenguajes como Python permiten algo similar. Quien trabaja a diario con esos entornos arrastra el hábito y lo aplica al escribir JSON sin darse cuenta. También aparece al editar a mano: se elimina el último elemento de una lista pero se olvida borrar la coma que lo precedía, o se copia un bloque intermedio, que sí llevaba coma, y se pega al final. Los archivos de configuración generados o editados manualmente son un caldo de cultivo típico. Como el editor no siempre marca el problema con claridad, la coma pasa desapercibida hasta que una herramienta que aplica la especificación real de JSON, como este validador, se detiene justo en ella.

El valor práctico del validador es que convierte un fallo escurridizo en una ubicación concreta. Cuando el analizador llega a la coma sobrante, se detiene y registra la posición: la línea y la columna donde el texto deja de ser válido. La herramienta le muestra ese punto y el motivo, de modo que no tiene que revisar todo el documento a ojo. Conviene saber que el mensaje a veces señala el carácter siguiente a la coma, por ejemplo la llave o el corchete de cierre, porque es ahí donde el analizador esperaba otro elemento y no lo encontró. En ambos casos la solución está justo antes: la coma que precede a ese cierre. Con la posición delante, borrar el carácter correcto es cuestión de segundos y no de una larga búsqueda.

Al corregir, la clave es quitar solo la coma que sobra y no las que separan elementos legítimos. Dentro de una lista, cada elemento se separa del siguiente con una coma, y esas comas son necesarias. La única que hay que eliminar es la que va después del último elemento, sin nada de la lista detrás salvo el cierre. En documentos grandes con objetos y arrays anidados puede haber más de una coma final, una por cada bloque afectado. Como el analizador señala un error cada vez, tras borrar la primera coma y volver a validar puede aparecer otra en un nivel distinto. No es que la herramienta falle: es su forma de trabajar, deteniéndose en el primer problema. Repitiendo validar y corregir irá limpiando todas las comas finales del documento una a una.

Todo este proceso ocurre de forma local en su navegador. El JSON que pega para localizar la coma no se sube a ningún servidor ni se almacena, así que puede depurar archivos de configuración con rutas internas o respuestas de API con datos reales sin exponerlos. Una vez corregido, formatear el JSON con una indentación clara ayuda a que estas comas se vean mejor en el futuro, porque una coma huérfana antes de un cierre resulta mucho más evidente en un documento bien alineado que en una sola línea comprimida. Para prevenir el problema de raíz, si su editor lo permite, active un formateador o un linter que elimine automáticamente las comas finales al guardar. Y ante cualquier duda, una pasada rápida por el validador antes de hacer commit le confirma que no queda ninguna.