Errores comunes en JSON y cómo corregirlos
JSON es el formato que usan muchas API, archivos de configuración y aplicaciones web para intercambiar datos, y su gramática cabe en una sola página. Por eso mismo no perdona: un texto o es JSON válido o no lo es, y basta una coma fuera de lugar para que un analizador (parser) lo rechace entero. La mayoría de los errores provienen siempre de los mismos pocos hábitos, muchos de ellos heredados de JavaScript o de otros lenguajes. Esta guía recoge las reglas, los errores que más a menudo las incumplen, cómo leer el mensaje de error y algunos casos que son JSON válido pero aun así causan problemas.
Las reglas que JSON tiene de verdad
Las definiciones vigentes son el RFC 8259, publicado en diciembre de 2017, y ECMA-404. Ambas describen la misma sintaxis:
- Las cadenas, incluidos todos los nombres de propiedad, van entre comillas dobles. No se permiten comillas simples.
- Los valores son cadenas, números, objetos, arrays o uno de tres literales: true, false y null, siempre en minúsculas.
- Los elementos de objetos y arrays se separan con comas, sin coma después del último.
- Los números se escriben en decimal, sin ceros a la izquierda, sin signo más y sin NaN ni Infinity.
- Dentro de una cadena hay que escapar la comilla doble, la barra invertida y los caracteres de control, como el salto de línea.
- No existe ninguna sintaxis para comentarios.
Entre tokens solo se admiten cuatro caracteres de espacio en blanco: el espacio, la tabulación, el avance de línea y el retorno de carro.
Los errores más comunes
Un analizador estándar rechaza todos estos ejemplos. La descripción indica cómo corregir cada uno.
{"name": "Ana",}Coma final: elimina la coma que sigue al último elemento de un objeto o de un array.{'name': 'Ana'}Comillas simples: usa comillas dobles en los nombres de propiedad y en las cadenas.{name: "Ana"}Nombre de propiedad sin comillas: todo nombre debe ser una cadena entre comillas dobles.{"a": 1 "b": 2}Falta una coma entre dos elementos, a menudo después de juntar líneas copiadas.{“name”: “Ana”}Comillas tipográficas, que los procesadores de texto y las aplicaciones de chat insertan automáticamente: sustitúyelas por comillas rectas ".{"note": 1 // total}Los comentarios no forman parte de JSON: elimínalos o pasa la nota a una propiedad.{"active": True}Literales con mayúscula: escribe true, false y null en minúsculas.{"value": undefined}undefined, NaN e Infinity existen en JavaScript, pero no en JSON: usa null o una cadena.{"code": 007}Los números no admiten ceros a la izquierda: escribe 7, o "007" como cadena si los ceros importan.{"path": "C:\Users"}Una sola barra invertida inicia una secuencia de escape, y \U no lo es. Peor aún: C:\new se aceptaría y se leería como C:, un salto de línea y ew. Escribe \\ para obtener una barra invertida literal.{"items": [1, 2}Un corchete o una llave que nunca se cierra, o que se cierra con el carácter equivocado: cada { necesita una } y cada [ necesita un ].
Cómo leer el mensaje de error
Un analizador lee el texto de izquierda a derecha y se detiene en el primer carácter que no puede aceptar, así que la posición que indica el mensaje de error es el punto en que se rindió, que a menudo está justo después del error real. Con una coma final, el analizador se queja de la llave de cierre, porque después de una coma espera otro nombre de propiedad. Si falta un corchete o una llave, el error puede aparecer al final mismo del texto, lejos de donde debería haber estado.
La redacción cambia según el navegador y el lenguaje, y muchos mensajes indican una posición, aunque no todos, ya sea como número de caracteres desde el principio o como línea y columna. Por ejemplo, el motor de JavaScript de Chrome informa así de {"name":"Ana",}:
Expected double-quoted property name in JSON at position 14 (line 1 column 15)Contando desde 0, la posición 14 es la llave de cierre; la coma que causó el error está un carácter antes.
Cuando la posición no sea evidente, fíjate en el carácter justo anterior y comprueba que cada corchete, llave o comilla que se abre antes de ese punto tenga su pareja. Con un editor que resalte las parejas de corchetes y llaves, a menudo es fácil detectar la que falta.
JSON válido que aun así da problemas
- Números grandes. JSON en sí no fija ningún límite, pero JavaScript, y muchos analizadores JSON de otros lenguajes, guardan los números en coma flotante de 64 bits, que solo garantiza enteros exactos hasta 9.007.199.254.740.991. En JavaScript, JSON.parse convierte 9007199254740993 en 9007199254740992 sin ningún aviso. Los identificadores grandes son más seguros como cadenas.
- Nombres de propiedad duplicados. El RFC 8259 dice que los nombres deberían ser únicos y que el software que recibe duplicados se comporta de forma impredecible. JavaScript se queda con el último valor: {"a": 1, "a": 2} se convierte en {"a": 2}.
- Una marca de orden de bytes. Algunos editores guardan los archivos UTF-8 con un carácter invisible U+FEFF al principio. El RFC 8259 prohíbe añadirlo al JSON que se envía por una red, y JSON.parse de JavaScript rechaza el texto que empieza por él.
- Un valor suelto en el nivel superior. Los estándares actuales (ECMA-404, y el RFC 7159, de 2014, y los posteriores) permiten que un texto JSON sea cualquier valor, como "hello" o 42, pero el anterior RFC 4627, de 2006, exigía un objeto o un array, y algunos analizadores más antiguos todavía lo exigen.
JSON no es JavaScript
La sintaxis de JSON se tomó de los literales de objeto de JavaScript, y por eso es tan fácil confundirlos. Un literal de objeto de JavaScript acepta comillas simples, nombres sin comillas, comas finales, comentarios y valores como undefined; JSON no acepta ninguno de ellos. Así, un código que funciona al pegarlo en un script puede fallar como archivo JSON.
Algunas herramientas aceptan formatos ampliados, como JSON5 o «JSON con comentarios» en archivos de configuración. Son prácticos allí donde se admiten, pero no son JSON, y un analizador estándar, incluido el formateador de nTools, los rechazará.
Preguntas frecuentes
¿Puede JSON tener comentarios?
No. La especificación no tiene sintaxis para comentarios. Si necesitas notas en los datos, ponlas en una propiedad como "_comment", o usa un formato que admita comentarios allí donde las herramientas lo permitan.
¿Por qué mi JSON funciona en JavaScript pero falla en un validador?
Porque un literal de objeto de JavaScript permite cosas que JSON no admite, como comillas simples, comas finales y nombres sin comillas. Pegado en el código, se ejecuta; guardado como JSON, no es válido.
¿Cómo mantengo exacto un número muy grande?
Envíalo como cadena, por ejemplo "9007199254740993", y conviértelo en el lado receptor con un tipo capaz de contenerlo, como BigInt en JavaScript.
¿El formateador de nTools envía mi JSON a algún sitio?
No. Se analiza y se formatea en tu navegador, y cuando el navegador indica una posición, el formateador la muestra como línea y columna.
Guías relacionadas
- Direcciones IP explicadas: IPv4, IPv6 y los rangos reservados
- Subredes y CIDR explicados: prefijos, máscaras y hosts utilizables
- Registros DNS explicados: A, AAAA, CNAME, MX, TXT y NS
- Marcas de tiempo Unix y zonas horarias explicadas
- Formatos de imagen explicados: JPEG, PNG, WebP, AVIF y HEIC
- Fortaleza de las contraseñas explicada: longitud, entropía y frases de contraseña
- Los UUID explicados: v4, v7 y cómo elegir la versión adecuada
- Los códigos QR explicados: capacidad, corrección de errores y tamaño de impresión
- Porcentajes e IVA explicados: añadir, quitar y encadenar
- Editar PDF en el navegador: qué se conserva al unir, dividir y convertir