¿Por qué mi JSON no es válido? Los errores más comunes

JSON es más estricto que JavaScript

JSON se parece a un objeto de JavaScript, y de ahí vienen casi todos los problemas: cosas que en JavaScript son perfectamente válidas no lo son en JSON. El formato lo define el RFC 8259 y es deliberadamente pequeño. JSON.parse() sigue esa gramática, y MDN recuerda que lanza un SyntaxError en cuanto el texto no la cumple.

Todos los ejemplos de abajo fallan en JSON.parse(). Hemos comprobado cada uno en una versión actual de Node.js.

1. Una coma final

{ "nombre": "Ana", "edad": 31, }

La coma después del último elemento es el error más frecuente de todos. JavaScript, muchos editores e incluso algunos formatos de configuración la permiten; JSON no. Lo mismo vale para los arrays: [1, 2, 3, ] es inválido. MDN pone los dos casos como ejemplos de JSON ilegal.

2. Comillas simples

{ 'nombre': 'Ana' }

Las cadenas de JSON van entre comillas dobles. Las simples no valen, ni en las claves ni en los valores. Si escribes JSON dentro de una cadena de JavaScript, usa comillas simples para la cadena de JavaScript y deja las dobles dentro, o escápalas.

3. Claves sin comillas

{ nombre: "Ana" }

En JSON toda clave es una cadena y lleva comillas dobles. Sin comillas es JavaScript válido, y por eso se cuela cuando alguien copia un objeto literal desde el código.

4. Comentarios

{ "nombre": "Ana" /* el usuario */ }

La gramática de JSON no tiene comentarios, ni // ni /* */. Los archivos de configuración que «admiten comentarios» usan una variante como JSONC o JSON5, no JSON propiamente dicho. Quita los comentarios antes de analizarlo o mueve la nota a un campo propio.

5. NaN, Infinity, undefined y valores de Python

{ "ratio": NaN, "limite": Infinity, "x": undefined }

El RFC 8259 lo dice sin rodeos: los valores numéricos que no se pueden representar en la gramática de números, como Infinity y NaN, no están permitidos. undefined no es un valor de JSON. Usa null o quita el campo. (JSON.stringify hace lo mismo al revés: convierte NaN e Infinity en null y omite las propiedades con valor undefined.) Aplica igual a True, False y None de Python, que aparecen cuando alguien pega la salida de print() en vez de la de json.dumps(): JSON exige true, false y null en minúsculas.

6. Números mal escritos

{ "a": 01, "b": +1, "c": .5, "d": 5., "e": 0x1F }

La gramática de los números es estrecha: sin ceros a la izquierda, sin signo más, con una cifra a cada lado del punto decimal y sin hexadecimal. Los cinco valores de arriba son inválidos. Suele venir de identificadores o códigos postales con ceros delante: si el cero inicial importa, guarda el valor como cadena ("01234").

7. Falta una coma (o sobra una)

{ "a": 1 "b": 2 }

Entre dos elementos tiene que haber una coma. Es típico al pegar una línea nueva en mitad de un objeto y olvidar añadir la coma a la línea anterior. El analizador suele señalar el comienzo de la segunda clave, no el sitio donde faltaba la coma.

8. Saltos de línea o tabuladores sin escapar dentro de una cadena

Una cadena no puede contener un salto de línea ni un tabulador reales; hay que escribirlos como las secuencias \n y \t. Un texto de varias líneas pegado tal cual entre las comillas rompe el análisis. Los caracteres por debajo de U+0020 deben ir escapados.

9. Comillas tipográficas y otros caracteres invisibles

Si copias JSON de un documento, un correo o un chat, las comillas rectas pueden haberse sustituido por tipográficas (“ ”), casi idénticas a la vista y no válidas como delimitadores. Lo mismo ocurre con los espacios de no separación y los caracteres de ancho cero. Una marca de orden de bytes (BOM) al principio del archivo también puede dar error: el RFC 8259 dice que las implementaciones no deben añadirla a un JSON transmitido por red. Si un documento parece correcto y falla, pégalo en el formateador y validador de JSON y mira dónde se detiene el analizador.

10. Texto cortado o vacío

«Unexpected end of JSON input» significa que el texto terminó antes de cerrar la estructura: falta una llave o un corchete de cierre, o se está analizando una cadena vacía. Comprueba que la respuesta no se cortó (una petición fallida, un límite de tamaño) y que no estás analizando un cuerpo vacío.

Dos cosas que son válidas y sorprenden

• Un valor suelto es JSON válido. 42, "hola" y null son textos JSON completos. Un documento no tiene por qué ser un objeto o un array.
• Las claves repetidas son válidas, pero peligrosas. { "a": 1, "a": 2 } se analiza sin error. Pero el RFC 8259 dice que los nombres dentro de un objeto DEBERÍAN ser únicos, y que cuando no lo son el comportamiento del programa que lo recibe es impredecible. Muchos analizadores se quedan con el último valor; no cuentes con ello.

Cómo encontrar el error rápido

1. Pega el texto en el formateador y validador de JSON. Te da la línea y la columna donde se detiene el análisis y explica el problema con palabras claras, y funciona en tu navegador, así que puedes pegar JSON con datos reales sin subirlo a ningún sitio. Si la intención es evidente, su reparación automática arregla los fallos habituales (comas finales, comillas simples, claves sin comillas, comentarios, valores de Python, comillas tipográficas) y te cuenta qué ha cambiado; revisa el resultado, porque una reparación es una suposición razonable, no una garantía.
2. Mira antes de la posición que indica el error, no solo en ella: una coma o unas comillas que faltan suelen señalarse en el elemento siguiente.
3. Una vez que se analiza, usa comparar dos JSON para ver qué ha cambiado entre dos versiones, o el minificador si lo necesitas compacto.
4. Si el objetivo es una hoja de cálculo, conviértelo con JSON a CSV cuando ya sea válido.

Si el JSON acaba en una hoja de cálculo, cómo abrir un CSV en Excel resuelve las tildes y los separadores; y si lleva tokens o datos codificados, cómo leer un JWT y qué es Base64 explican cómo interpretarlos.

Fuentes y más información

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• MDN: JSON.parse() (ejemplos de JSON ilegal)

Datos comprobados el 3 de octubre de 2026.