El JSON falla al parsearse porque algo del texto no está en la gramática, y los sospechosos de siempre son una coma final, comillas simples, una clave sin comillas, un comentario o un byte order mark invisible justo al principio. El mensaje de error nombra el carácter donde el parser se rindió. Ese carácter está en el error o inmediatamente después, nunca antes, porque un parser lee de izquierda a derecha y todo lo que pasó todavía era válido.
Los mensajes de abajo vienen de Node 22, que usa el mismo motor de JavaScript que Chrome. Firefox y Safari los redactan distinto, así que toma el texto exacto como un ejemplo y la posición como lo útil.
¿Qué dice el error para cada equivocación y adónde apunta?
| Lo que escribiste | Lo que dice el mensaje | Adónde apunta |
|---|---|---|
{"a":1,} | Se esperaba un nombre de propiedad entre comillas dobles | La llave de cierre, un carácter después de la coma |
[1,2,] | Token ']' inesperado | El corchete de cierre, sin ninguna posición |
{'a':1} o {a:1} | Se esperaba un nombre de propiedad o '}' | El primer carácter de la clave |
{"a":1 // nota} | Se esperaba ',' o '}' después del valor de la propiedad | La primera barra |
| Un archivo guardado con byte order mark | Token inesperado, mostrado como un par de comillas con aspecto vacío | El primer carácter, sin posición |
La ubicación suele ser honesta. Lo que engaña es la redacción, porque el parser describe lo que esperaba, no lo que tú querías decir.
¿Por qué se le echa la culpa al corchete por una coma final?
Después de una coma, la gramática exige otro valor u otro miembro. Cuando el parser se encuentra con } o ] en su lugar, ahí se detiene. La coma que aceptó un instante antes estaba bien por lo que él sabía, así que el reporte cae en el carácter de cierre y el error es el carácter anterior.
El mensaje cambia según el contenedor. En un objeto dice que esperaba un nombre de propiedad entre comillas dobles. En un array dice solo que el corchete era inesperado, y en ese caso el formateador de este sitio muestra el mensaje sin línea ni columna, porque el mensaje no trae posición que leer. Busca una coma justo antes de la primera llave o corchete de cierre que veas cerca de donde el archivo empieza a fallar.
Las comas finales son legales en JavaScript, y por eso se escriben. No son JSON válido, y ningún parser estricto las acepta.
¿Por qué las comillas simples y las claves sin comillas dan el mismo mensaje?
Las dos rompen la misma regla: la clave de un objeto debe ser un string entre comillas dobles. Una clave entre comillas simples y una clave sin comillas empiezan con un carácter que el parser no esperaba en esa posición, así que informa lo mismo. El mensaje dice que esperaba un nombre de propiedad, lo cual suena absurdo cuando estás viendo uno ahí mismo.
El arreglo es mecánico para las claves y riesgoso para los valores. Un valor entre comillas simples da otro mensaje distinto (un token inesperado, sin posición en Chrome), y un buscar y reemplazar global de ' por " arruinará cualquier string que contenga un apóstrofo. Arregla primero las claves y después los valores a ojo. Si el texto salió de un print de Python o de un objeto literal de JavaScript, serialízalo bien en el origen.
¿Por qué un comentario dice que se esperaba una coma?
Acaba de terminar un valor, así que el parser busca una coma o una llave de cierre. Encuentra una barra y lo reporta, sin decir nada de comentarios. La posición es exacta: apunta a la primera barra del comentario.
El formato no tiene sintaxis de comentarios porque se quitó a propósito. Por qué JSON no tiene comentarios cuenta quién los quitó y qué archivos de configuración leen un dialecto más flexible de todos modos. La prueba práctica es que tsconfig.json tolera comentarios y package.json no, así que la extensión del archivo no te dice nada.
¿Por qué un archivo que se ve bien falla en el primer carácter?
Un byte order mark es el carácter U+FEFF al comienzo de un archivo; algunos editores lo escriben cuando guardas como «UTF-8 con BOM». No se dibuja nada, así que el archivo se ve perfecto, y el parser ve un carácter que no es espacio en blanco ni un valor. El RFC 8259 dice que quien genera JSON no debe añadirlo en textos enviados por red y que un parser puede ignorarlo en vez de tratarlo como error. El JSON.parse de Chrome no lo ignora.
La pista es el mensaje: un token inesperado seguido de un par de comillas sin nada visible en medio, y sin posición. Si ves eso, el problema no está en el texto que puedes leer. Borra el primer carácter o vuelve a guardar el archivo como UTF-8 plano, sin BOM.
A la misma familia pertenecen un espacio de no separación después de la última llave, que vuelve como «carácter inesperado que no es espacio en blanco después del JSON», y las comillas tipográficas pegadas desde un documento. Los caracteres invisibles en un texto muestra cómo encontrar el primer caso, y por qué el texto pegado desde Word sale mal cubre el segundo.
¿Cómo encuentras el error cuando el mensaje no ayuda?
Pega el texto en el formateador de JSON. Cuando el mensaje del navegador incluye una posición, la herramienta la convierte en línea y columna, que es mucho más fácil de usar que un desplazamiento de caracteres. Arregla ese error, pega de nuevo y espera uno distinto: el parser solo reporta el primer problema, así que un archivo con seis errores lleva seis rondas.
Si el archivo es grande, está minificado o el mensaje no trae posición, pártelo por la mitad:
- Quédate con todo hasta un punto donde acaba de terminar un miembro o un elemento completo. Borra el resto.
- Cierra a mano los corchetes y llaves que quedaron abiertos.
- Si se parsea, la falla está en la mitad que quitaste. Si sigue fallando, está en la que dejaste, y esa la partes de nuevo.
Cada ronda reduce la búsqueda a la mitad, así que un archivo de unos pocos miles de registros lleva una docena de intentos. En un array de registros de nivel superior es todavía más rápido borrar registros desde el final hasta que el error desaparezca. El primer registro que lo trae de vuelta es el culpable. La guía de JSON minificado tiene la versión de contar columnas para un archivo que está todo en una sola línea.
¿Qué no puede decirte el formateador?
Te dice que el archivo no es JSON válido y, cuando el navegador da una posición, dónde se detuvo. No sugiere una corrección y no repara nada. Tampoco distingue un error en tus datos de un archivo que nunca fue JSON: JSON5, JSONC y los logs de un objeto por línea fallan igual, como dicen las notas del propio formateador. La redacción y la presencia de una posición dependen del navegador en que lo ejecutes, así que la misma entrada puede dar un mensaje un poco distinto en otro.
Todo corre en la pestaña. El texto no se sube a ningún lado, lo cual importa cuando el archivo es una configuración con un token adentro.
Cuando el error es una posición que no logras interpretar, el formateador de JSON la convierte en una línea y una columna y corre entero en tu navegador, así que una configuración con credenciales se queda en tu máquina.
Si la causa resultó ser un comentario que estabas seguro de que debía estar permitido, por qué JSON no tiene comentarios explica la historia y qué usar en su lugar.
Preguntas frecuentes
¿Por qué JSON.parse dice «unexpected token» sin ninguna posición?
En los motores de la familia de Chrome, algunos errores (una coma final en un array, un valor entre comillas simples, NaN, un byte order mark) informan solo el token inesperado y una copia de la entrada, sin posición. El texto sigue siendo inválido en ese token o antes. Trabaja desde el principio del texto, o parte la entrada a la mitad hasta que el error desaparezca.
¿Se permite una coma final en JSON?
No. La gramática admite una coma solo entre dos valores o miembros, así que una coma antes de un corchete o llave de cierre es un error de sintaxis en todo parser estricto. Los objetos literales de JavaScript y algunos dialectos como JSON5 la aceptan, y por eso se escribe tantas veces por error.
¿Por qué mi archivo JSON falla si se ve completamente válido?
Revisa los caracteres que no se ven. Un byte order mark al comienzo del archivo, un espacio de no separación o comillas tipográficas pegadas desde un documento parecen texto válido y hacen fallar el parseo. Volver a guardar como UTF-8 plano sin BOM y reescribir los caracteres sospechosos suele arreglarlo.
¿Cómo encuentro el error en un archivo JSON muy grande?
Arregla el primer error reportado y vuelve a parsear, porque el parser se detiene en el primer problema. Si la posición no sirve, corta el archivo en un registro completo, cierra los corchetes y prueba cada mitad. La mitad que falla contiene la falla, y repetir el corte la acota rápido.
¿Un byte order mark vuelve inválido un JSON?
El RFC 8259 dice que un texto JSON enviado por red no debe empezar con uno, y que un parser puede ignorarlo en vez de tratarlo como error. «Puede» significa que algunos lo hacen y otros no, y el JSON.parse de Chrome lo rechaza. Lo más seguro es un archivo sin él.
Última actualización 4 de noviembre de 2026
