Validador JSON gratuito

Validación JSON: dos capas, dos preguntas distintas

Un validador JSON responde a una pregunta binaria, ¿es este documento JSON bien formado?, entregando la entrada al mismo parser que el navegador usa internamente y reportando si acepta la sintaxis. Esta herramienta hace eso y solo eso. No verifica si los datos dentro del documento significan lo que tú querías. Esa segunda pregunta, ¿tiene el documento la forma, los tipos y las restricciones que tu aplicación espera?, es la validación de esquema, el territorio de herramientas como Ajv (tratada más abajo). Las dos actividades se complementan y responden a preguntas distintas; usar una cuando querías la otra es un error de categoría. Una analogía útil es la distinción corrector-ortográfico / corrector-gramatical en procesadores de texto: el ortográfico (sintaxis) te dice si cada palabra es una palabra real; el gramatical (esquema) te dice si la frase tiene sentido; ambos son útiles, ninguno reemplaza al otro, y ninguno te dice si el ensayo es bueno. {"phoneNumber": 12345} es JSON bien formado, pero si tu aplicación esperaba una cadena formateada como "+1-555-555-1234", está mal, y un validador de sintaxis no puede decírtelo.

Más allá del chequeo sintáctico, esta herramienta también ofrece una pasada de «Corregir problemas comunes» al mejor esfuerzo que reescribe las cuatro formas más frecuentes en que los desarrolladores escriben sin querer JSON inválido: comas finales, cadenas entre comillas simples, claves sin comillas y literales undefined (reescritos como null). Es una heurística, no un parser, así que revisa siempre la salida corregida antes de adoptarla.

Una breve historia de JSON

JSON tiene una biografía notablemente corta. El acrónimo se acuñó en State Software, Inc., una pequeña consultora que Douglas Crockford y Chip Morningstar cofundaron en marzo de 2001 para construir lo que luego se llamaría aplicaciones web Ajax. El primer mensaje JSON se envió en abril de 2001 desde un ordenador en el garaje de Morningstar en el Área de la Bahía. Crockford no afirma haber inventado JSON, el formato ya existía dentro del lenguaje JavaScript como subconjunto de objeto-literal; su contribución fue desprenderlo, darle un nombre, montar un sitio (json.org apareció en 2002 con una descripción de la gramática en tres notaciones y un parser de referencia en JavaScript) y abogar por su adopción. Diciembre de 2005 es el momento que la mayoría de los historiadores señalan como la entrada de JSON al mainstream: ese mes, Yahoo! comenzó a ofrecer algunos de sus servicios web en JSON. La IETF lo tomó después: RFC 4627 («The application/json Media Type for JSON»), del propio Crockford, se publicó en julio de 2006 como documento informacional, no Standards Track. Los organismos de estandarización se pusieron al día en 2013-2014: ECMA-404 1.ª edición en octubre de 2013 (deliberadamente mínima, seis páginas de contenido sustantivo), RFC 7159 en marzo de 2014 (relajó la restricción de nivel superior para que cualquier valor JSON, no solo objetos y arrays, pudiera ser documento completo), y el par actual en diciembre de 2017: RFC 8259 (ahora Internet Standard STD 90) y ECMA-404 2.ª edición alineada normativamente con ella. Las dos están emparejadas: cada una referencia normativamente a la otra y contiene un compromiso de mantenerlas consistentes. También publicada como ISO/IEC 21778:2017.

La gramática JSON en 200 palabras

Un documento JSON es un solo valor, opcionalmente rodeado de espacios en blanco. Existen exactamente seis tipos de valores: objeto, una colección no ordenada de cero o más pares nombre/valor, escrita {"k": v, "k2": v2}; array, una secuencia ordenada, [v, v2, v3] (los arrays preservan el orden por spec); cadena, una secuencia de caracteres Unicode envuelta en comillas dobles (comillas simples no permitidas; escapes con barra invertida \", \\, \/, \b, \f, \n, \r, \t más \uXXXX; los caracteres de control U+0000 a U+001F deben escaparse); número, una forma ASCII estricta (signo menos opcional, parte entera sin ceros a la izquierda, parte fraccional opcional, exponente opcional con e o E); true / false, los booleanos JSON, solo en minúsculas; null, la ausencia de valor, solo en minúsculas. Los espacios entre tokens están permitidos e ignorados. Sin comentarios. Sin comas finales. Las claves de objeto deben ser cadenas entre comillas dobles. La gramática cabe en una página. La forma estricta de número prohíbe hex (0xFF), octal (0777), signo +, Infinity, NaN y puntos decimales finales como 1.; esto atrapa a cualquiera que escriba JSON a mano en entornos que aceptan las formas numéricas ECMAScript más laxas, más comúnmente, a cualquiera que haya pegado un código de color hex en un archivo JSON.

Por qué la gramática es tan estricta, las decisiones de diseño de Crockford

Dos omisiones deliberadas explican casi toda la fricción que los usuarios sienten al escribir JSON a mano. Sin comentarios. JavaScript tiene // y /* */; JSON, subconjunto de JavaScript, no tiene ninguno. La razón declarada por Crockford, publicada en Google+ en 2012, se ha citado miles de veces desde entonces: «Quité los comentarios de JSON porque vi que la gente los usaba para guardar directivas de parsing, práctica que habría destruido la interoperabilidad. Sé que la falta de comentarios entristece a algunas personas, pero no debería.» El argumento es que los comentarios invitan a la extensión, si // @schema foo.json está en tu config y tu herramienta lo lee, entonces tu archivo de config ya no es JSON. Sin comas finales. Una coma es un separador, no un terminador. [1, 2, 3] es legal pero [1, 2, 3,] no lo es. La razón es la misma que para los comentarios: simplicidad de la gramática y uniformidad entre parsers. El coste es que cualquiera que edite un objeto JSON multilínea, añadir una propiedad, reorganizar propiedades, eliminar la última, tiene que pensar en la coma. Sin undefined. JavaScript tiene undefined; JSON no. Usa null u omite la propiedad por completo. BOM en la entrada. Un byte-order mark (U+FEFF) al inicio de un documento JSON está prohibido en JSON transmitido, pero los parsers PUEDEN ignorar uno si aparece. En la práctica, los archivos guardados como «UTF-8 with BOM» por editores Windows más antiguos rompen silenciosamente algunos parsers y funcionan silenciosamente en otros.

Errores JSON habituales:

• Comas finales: el último elemento de un objeto o array no puede llevar coma
• Apóstrofos en lugar de comillas dobles: JSON solo admite comillas dobles para las cadenas
• Claves sin comillas: las claves de objeto deben ir siempre entre comillas dobles
• Comentarios: JSON no admite comentarios (aunque algunas herramientas los acepten)
• Barra invertida no escapada. Dentro de una cadena JSON, \ es el carácter de escape. "C:\Users\Alice" falla porque \U y \A no son escapes reconocidos. La cura es duplicar cada barra invertida: "C:\\Users\\Alice".
• Caracteres de control no escapados. Un salto de línea, tabulador u otro carácter literal en U+0000-U+001F dentro de una cadena JSON está prohibido. La mayoría de los usuarios chocan con esto al pegar una cadena multilínea en un valor JSON sin escapar los saltos como \n.
• NaN e Infinity. Fuera de la gramática JSON. El JSON.parse del navegador los rechaza. JSON.stringify produce null cuando se le pide serializar NaN o Infinity, así que el ida-y-vuelta pierde información silenciosamente.
• Entrada vacía. Lanza «Unexpected end of JSON input». El truco es que una respuesta HTTP que volvió con Content-Type: application/json pero cuerpo vacío produce este error en cadenas fetch().then(r => r.json()).

JSON Schema, el estándar para validar la forma

JSON Schema es un vocabulario basado en JSON para describir la estructura y restricciones de documentos JSON. La primera propuesta la envió Kris Zyp en octubre de 2007; la serie de Internet-Drafts de la IETF comenzó con draft-zyp-json-schema-00 el 5 de diciembre de 2009. Los drafts sucesivos evolucionaron a través de media docena de autores y editores durante la siguiente década y media. La versión estable actual es el draft 2020-12 (el nombre «2020-12» se refiere al snapshot de desarrollo del que derivó; el lanzamiento formal real fue el 16 de junio de 2022). Las cuatro palabras clave de aserción más usadas cargan con la mayor parte del trabajo diario: type (restringe un valor a uno de los seis tipos JSON o a una lista de tipos aceptables), required (lista de nombres de propiedades que un objeto debe contener), properties (mapa de nombre de propiedad a sub-esquema para el valor), e items (un esquema aplicado a cada elemento de un array). Combinadas con minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, etc.) y las palabras clave compuestas (allOf, anyOf, oneOf, not), JSON Schema puede expresar casi cualquier restricción de «forma» que tus datos necesiten satisfacer. El esquema es a su vez un documento JSON, lo que es recursivo de una forma que algunos consideran elegante y otros mareante.

Ajv, el validador de esquema JavaScript dominante

Si quieres hacer validación de esquema en JavaScript, la respuesta canónica es Ajv (Another JSON Schema Validator) de Evgeny Poberezkin. Su truco es compilar el esquema a JavaScript optimizado: en lugar de recorrer el esquema y el árbol de datos en tiempo de ejecución, genera una función que hardcodea cada chequeo y corre a velocidad nativa. Esto lo hace dramáticamente más rápido que validadores ingenuos en documentos grandes y caminos de validación calientes. Ajv soporta los drafts JSON Schema 04, 06, 07, 2019-09 y 2020-12; es el validador integrado en express-validator, la validación de peticiones de AWS API Gateway y muchos de los principales frameworks Node.js. Para Python, la elección canónica es jsonschema de Julian Berman; para Java, el json-schema-validator de Networknt. El punto es que la validación de esquema es un problema resuelto, maduro y bien instrumentado, pero es un problema en el que tienes que optar entrando: escribir el esquema. Esta herramienta no escribe el esquema por ti; solo hace validación sintáctica.

JSON5 y JSONC, los superconjuntos relajados

JSON5 es un superconjunto formal de JSON especificado en json5.org, originalmente diseñado por Aseem Kishore en 2012 y ahora mantenido por Jordan Tucker. Permite todo lo que JSON estricto prohíbe: comentarios (// y /* */), comas finales, cadenas entre comillas simples, claves de objeto sin comillas (cuando son identificadores ECMAScript válidos), números hexadecimales, puntos decimales iniciales/finales (.5 o 5.), Infinity y NaN, y números con signo. Los documentos JSON5 suelen usar la extensión .json5 y se parsean con bibliotecas como el paquete npm json5. JSONC es el modo informal «JSON with Comments» de Microsoft, usado en los archivos de configuración de VS Code (settings.json, launch.json, tasks.json). Los comentarios están permitidos por spec; las comas finales son toleradas por el parser de referencia pero marcadas con advertencias. Las formas relajadas son para archivos de configuración editados a mano donde la disciplina del JSON estricto estorba; para intercambio máquina-a-máquina, el JSON estricto sigue siendo la elección correcta. Esta herramienta usa el JSON.parse estricto del navegador y por tanto rechazará ambos, quita comentarios y comas finales antes de pegar, o usa un parser JSON5/JSONC para convertir primero a JSON estricto.

Validadores en streaming para entradas muy grandes

El JSON.parse del navegador carga el documento entero en memoria como un único árbol de objetos. Para la mayoría de las entradas está bien; para archivos de log, exports de API de varios gigabytes o volcados de datos de sensores, no. El enfoque de streaming es consumir el documento como un flujo de tokens y emitir eventos («inicio de array», «valor de cadena», «clave de objeto») sin retener nunca toda la estructura en memoria. clarinet de Marak Squires es el parser JSON streaming Node.js canónico, modelado sobre el patrón del parser SAX XML. Oboe.js de Jim Higson (originado en su tesis de 2013) es el equivalente compatible con navegador, diseñado para consumir JSON sobre fetch según fluye y emitir eventos para cada JSONPath coincidente; ya no se mantiene activamente pero la técnica que pionerizó sigue siendo útil. JSONStream en npm envuelve clarinet para uso Node compatible con pipes. Una herramienta puramente de navegador como esta está limitada por la memoria disponible; si validas JSON a escala de gigabytes, ejecuta un parser de streaming en Node o usa jq --stream en línea de comandos.

Dónde la validación JSON importa en flujos de trabajo reales

Los archivos de configuración son el caso de mayor apalancamiento: tsconfig.json, package.json, configs de ESLint y Prettier, Docker Compose, políticas AWS IAM. Un solo carácter inválido puede romper el build; un validador sintáctico lo atrapa antes que el build. Las respuestas de API son lo siguiente: desarrollar contra una API externa a menudo significa mirar un payload y preguntarse «¿esto es realmente JSON válido?» antes de cazar un bug de parsing más profundo. Las cargas útiles de webhooks, eventos de Stripe, disparadores de GitHub Actions, webhooks entrantes de Slack, son JSON; un pegar-y-validar rápido atrapa los casos donde una firma malformada o un byte errante ha corrompido el cuerpo. Las entradas de log (logs estructurados de Splunk, Datadog, Loki) son JSON línea-a-línea; una línea mala rompe toda la canalización de ingesta. Los archivos JSON generados (lockfiles, manifiestos de build, fixtures de test) a veces derivan de forma ruidosa durante desarrollo normal; un validador sintáctico atrapa los casos donde el propio paso de generación falló.

Los límites honestos de un validador solo-sintaxis

Un validador sintáctico no puede atrapar errores de lógica. No puede decirte que un campo «phone number» contiene un entero en vez de una cadena; que una cadena «date» está malformada pero resulta ser una cadena válida; que falta un campo obligatorio; que un número que debería ser positivo es negativo; que dos campos que deberían coincidir no lo hacen. Todo eso son problemas de validación de esquema. La canalización correcta para un sistema en producción es: (1) validación sintáctica como primera barrera, ¿esto parsea como JSON siquiera? (2) validación de esquema como segunda barrera, ¿tiene la forma esperada? (3) validación de lógica de negocio como tercera barrera, ¿los datos tienen sentido dado otro estado? Existen herramientas para las tres capas; esta solo maneja la primera. La ventaja de pegar un payload primero en un validador sintáctico es que aísla el modo de fallo más barato y común (una coma errante, una llave faltante) de los errores de esquema más costosos que de otro modo los ahogarían.

Privacidad: por qué importa el solo-navegador aquí

Validar JSON en un servidor requiere subir el documento. Para ejemplos ordinarios de datos públicos es inofensivo. Para respuestas de API que contienen tokens de autenticación, PII de clientes, registros internos de empleados, secretos de configuración o datos de producto sin publicar, no lo es. Incluso con la política de eliminación más escrupulosa, la subida queda en logs del servidor, posiblemente en una caché CDN, posiblemente en una canalización de analítica, posiblemente en un backup. Esta herramienta ejecuta JSON.parse en tu navegador vía JavaScript. El documento pegado nunca cruza la red, verifícalo en la pestaña Network de DevTools al pulsar un botón, o pon la página offline (modo avión) tras cargar y confirma que el validador sigue funcionando. Segura para validar payloads de webhook con secretos, respuestas de API con cabeceras de autenticación, archivos de config con credenciales de base de datos, o cualquier otro JSON que no quieras ver copiado en el disco duro de un desconocido.

Preguntas frecuentes

¿Qué es un JSON válido?

Un JSON válido debe ser uno de estos tipos: objeto ({}), array ([]), cadena (""), número, booleano (true/false) o null. Todas las cadenas y claves de objeto deben usar comillas dobles. Los números no pueden llevar ceros a la izquierda. Se permiten espacios entre los elementos.

¿Qué hace «Corregir problemas habituales»?

La corrección intenta arreglar automáticamente los errores frecuentes: comas finales, apóstrofos convertidos a comillas dobles, claves sin comillas y valores undefined convertidos a null. Es una herramienta heurística que puede no corregirlo todo, revisa el resultado con atención.

¿Cómo validar JSON en mi aplicación?

En JavaScript: usa JSON.parse() y captura los errores. En Node.js: fs.readFileSync() + JSON.parse(). En Python: json.loads() o json.load(). La mayoría de los lenguajes disponen de bibliotecas JSON integradas.

¿Puedo validar JSON5 o JSONC (JSON con comentarios)?

No directamente. Esta herramienta usa el JSON.parse estricto del navegador, que sigue RFC 8259, comentarios, comas finales, comillas simples y claves sin comillas son errores de sintaxis. Si tu entrada es JSON5 (json5.org, Aseem Kishore 2012, mantenido por Jordan Tucker) o JSONC de VS Code, instala el paquete npm json5 o el paquete jsonc-parser, convierte a JSON estricto y luego valida. La pasada «Corregir problemas comunes» maneja un subconjunto de las diferencias pero no es un parser JSON5 / JSONC completo.

¿Hay un límite de tamaño?

Sin límite estricto, pero el JSON.parse del navegador carga el documento entero en memoria como un solo árbol de objetos. Decenas de miles de líneas funcionan cómodamente; volcados de log de varios gigabytes agotarán la memoria. Para JSON muy grande, ejecuta un parser de streaming como clarinet (Marak Squires) u Oboe.js (Jim Higson, 2013), o usa jq --stream en línea de comandos, que puede procesar documentos de tamaño arbitrario sin cargar nunca todo el contenido.

¿Mis documentos JSON se suben?

No. JSON.parse corre en tu navegador vía JavaScript. El documento pegado nunca cruza la red, verifícalo en la pestaña Network de DevTools al pulsar Validate, o pon la página offline tras cargar y confirma que la herramienta sigue funcionando. Segura para validar payloads de webhook con secretos, respuestas de API con cabeceras de autenticación, o archivos de config con credenciales de base de datos.