JSON Validator

Qué valida realmente un validador JSON

Un validador estricto no comprueba solo que las llaves y corchetes cierren: valida tipos primitivos (string, number, boolean, null, object, array), que las claves de un objeto sean cadenas entre comillas dobles, que los números no lleven ceros a la izquierda ni la coma decimal, y que no existan comas finales tras el último elemento de un array u objeto. {"nombre": "Ana", "edad": 30,} es inválido precisamente por esa coma final, algo que en JavaScript o en YAML pasaría desapercibido. También detecta claves duplicadas si el motor lo soporta, aunque el propio RFC 8259 deja ese caso como comportamiento no especificado, así que conviene no depender de él.

El error 'Expecting property name enclosed in double quotes'

Este mensaje aparece cuando una clave no lleva comillas dobles, como en {nombre: "Ana"}, o cuando se usan comillas simples: {'nombre': 'Ana'}. JSON no admite ninguna de las dos formas, aunque ambas sean JavaScript válido dentro de un objeto literal. Es el error más frecuente al copiar configuración desde código JavaScript a un fichero .json real, porque el editor no avisa hasta que un parser estricto como el de Python o el de este validador lo rechaza. La solución es mecánica: envolver cada clave entre comillas dobles rectas, nunca tipográficas ( o ''`), que tampoco son válidas.

Comas finales, comas ausentes y el mensaje 'Expecting , delimiter'

Al ejecutar json.loads('{"nombre": "Ana" "edad": 30}') en Python el error exacto es Expecting ',' delimiter: line 1 column 18 (char 17): falta la coma entre dos pares clave-valor. El caso inverso, una coma sobrante justo antes de } o ], produce en el mismo intérprete Illegal trailing comma before end of object: line 1 column 29 (char 28). Node.js con JSON.parse da un mensaje distinto pero apunta a la misma causa: Unexpected token '}', ...is not valid JSON. Ninguno de los tres motores acepta comas finales, a diferencia de JavaScript moderno o de JSON5, así que si el fichero se genera con una plantilla, hay que eliminar la coma del último elemento de forma explícita.

Escapes de cadenas y caracteres de control sin escapar

Dentro de una cadena JSON, una barra invertida solo puede preceder a los caracteres \", \\, \/, \b, \f, \n, \r, \t o una secuencia \uXXXX. Una ruta de Windows como "C:\Users\ana" es inválida porque \U y \a no son escapes reconocidos; hay que duplicar cada barra: "C:\\Users\\ana". Igual de habitual es pegar un salto de línea literal dentro de una cadena copiada de un editor de texto: JSON exige que los caracteres de control (código menor que 0x20) se representen como \n, \r o \uXXXX, nunca como bytes crudos dentro de las comillas.

Números, `NaN`, `Infinity` y otros valores que no existen en JSON

JSON no define NaN, Infinity, -Infinity ni números octales u hexadecimales (0x1F). Son extensiones que Python permite por defecto con json.loads y que JSON.stringify de JavaScript convierte silenciosamente en null, generando una pérdida de datos que pasa desapercibida si no se valida antes de serializar. Tampoco se permite un punto decimal sin dígitos a un lado, como .5 o 5.; el formato correcto exige al menos un dígito antes y después del punto (0.5). Un validador estricto marca estos casos aunque el lenguaje de origen los tolere.

BOM, codificación y JSON con líneas (JSON Lines)

Un BOM (Byte Order Mark, EF BB BF en UTF-8) al principio del fichero hace que algunos parsers estrictos fallen con un error de token inesperado en la posición 0, aunque el resto del documento sea válido; conviene guardar siempre en UTF-8 sin BOM. Distinto es el formato JSON Lines (.jsonl), donde cada línea es un objeto JSON independiente en vez de un único array raíz: es habitual en logs y en exportaciones de bases de datos, y un validador de JSON estándar lo rechazará si se le pasa el fichero completo como un solo documento, porque varios objetos consecutivos sin separador no forman un valor JSON válido.

De la validación a la conversión: JSON, YAML y minificación

Una vez el JSON es válido, las tareas típicas son formatearlo con sangría legible, minificarlo para producción o convertirlo a otro formato de configuración. Para pasar entre JSON y YAML sin perder tipos (fechas, booleanos, null) conviene usar una herramienta dedicada como el conversor JSON/YAML de este sitio en vez de una transformación manual, porque YAML introduce matices —como el problema de Noruega o los booleanos implícitos— que no existen en JSON y que se explican en el artículo dedicado a validación YAML.

Salidas reales de ejemplo

$ python3 -c "import json; json.loads(open('config.json').read())"
Traceback (most recent call last):
  ...
json.decoder.JSONDecodeError: Illegal trailing comma before end of object: line 1 column 29 (char 28)

$ python3 -c "import json; json.loads('{\"nombre\": \"Ana\" \"edad\": 30}')"
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 18 (char 17)

$ echo '{"nombre": "Ana", "edad": 30,}' > bad.json
$ jq . bad.json
jq: parse error: Expected another key-value pair at line 1, column 30

$ node -e "JSON.parse('{nombre: \"Ana\"}')"
SyntaxError: Unexpected token n in JSON at position 1

{
  "nombre": "Ana",
  "edad": 30,
  "ruta": "C:\\Users\\ana"
}

Casos de uso comunes

• Depurar un fichero de configuración (`package.json`, `tsconfig.json`) que una aplicación rechaza al arrancar.
• Verificar la respuesta de una API antes de integrarla, cuando el payload se copia manualmente desde un log.
• Limpiar JSON exportado desde Excel o Google Sheets, que suele añadir comillas simples o comas finales.
• Comprobar que un JSON generado por una plantilla o un script no dejó comas colgando en el último elemento.
• Formatear o minificar un JSON antes de pegarlo en documentación técnica.
• Enseñar a un equipo júnior a leer los mensajes de error de `JSON.parse` o `json.loads` con ejemplos reales.

Buenas prácticas

• Guarda siempre los ficheros JSON en UTF-8 sin BOM para evitar errores de token en la posición 0.
• No confíes en que un editor de texto genere JSON válido al copiar un objeto JavaScript; valida antes de guardar.
• Automatiza la validación en CI con `jq . fichero.json > /dev/null` o un linter de JSON antes de desplegar configuración.
• Si necesitas comentarios o comas finales, usa JSON5 o JSONC de forma explícita, no fuerces JSON estándar.
• Para contratos de API, complementa la validación sintáctica con un JSON Schema que fije tipos y campos obligatorios.
• Cuando conviertas a YAML, revisa después con un validador YAML: los tipos implícitos pueden cambiar el significado.

Referencias oficiales

• RFC 8259 — The JavaScript Object Notation (JSON) Data Interchange Format
• MDN — JSON.parse()
• jq Manual