📐 Validador JSON Schema
Valida JSON usando JSON Schema. Muestra errores con información de ubicación, incluidos desajustes de tipo, propiedades requeridas faltantes, valores fuera del enum y violaciones de expresiones regulares. Compatible con Draft 7, 2019-09 y 2020-12.
El resultado aparecerá aquí.
🔗 Herramientas relacionadas
📖 Dónde se suele tropezar
Ejecuta JSON Schema (Draft 7, 2019-09 y 2020-12) con Ajv 8 y comunica discrepancias de tipo, propiedades obligatorias ausentes, valores fuera de un enum y demás, cada uno con su ruta de campo. Todo se ejecuta en el navegador. Cero errores no significa que los datos sean correctos: un esquema laxo lo acepta todo. Casi todas las dificultades con JSON Schema se reducen a que una restricción que creías haber escrito no está realmente en vigor.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Declaras format email y pasan direcciones inválidas | format es una anotación por defecto y no valida. No es un atajo de la implementación sino la especificación tal cual está escrita: la aserción de format se define como vocabulario opcional, de modo que una implementación puede ignorarla y seguir siendo conforme. Ajv no es distinto: sin cargar ajv-formats aparte, email, date-time, uri y uuid pasan de largo. Lo incómodo es que quien escribió el esquema cree que valida mientras el motor lo deja pasar todo, y nadie se entera hasta producción. |
En el servidor, añade siempre ajv-formats: dos líneas, const addFormats = require("ajv-formats"); addFormats(ajv);. Si prima la portabilidad, una expresión regular en pattern es la opción segura y se comporta igual en toda implementación. (Una regex completa para direcciones de correo no es viable, así que quédate en algo como ^[^@\s]+@[^@\s]+\.[^@\s]+$ y demuestra la existencia con un correo de confirmación.) Cuando compartas un esquema, indica si se espera que format se afirme: si queda implícito, la firmeza de la validación depende de qué implementación lo ejecute. |
| Declaras required y aun así pasa sin la propiedad | Casi siempre está en el sitio equivocado. required va directamente en el esquema del objeto, como un array de nombres de clave: {"type":"object","properties":{...},"required":["id","name"]}. Escribir "required": true dentro de properties es sintaxis de Draft 3, y los drafts actuales lo ignoran sin más como palabra clave desconocida: ni siquiera da error, así que nada te avisa. Por el mismo motivo, una errata como requred o minLenght también se ignora en silencio. |
Ejecuta Ajv con strict: true. Así informa como errores de las palabras clave desconocidas y de las declaraciones de tipo contradictorias, lo que saca a la luz toda restricción que no estaba haciendo nada. Además, escribe pruebas para el propio esquema, y lo esencial es incluir al menos un documento que deba ser rechazado, no sólo documentos que deban pasar: una batería sólo de los segundos pasa incluso con un esquema vacío. Las propiedades obligatorias de un objeto anidado van dentro del esquema de ese objeto; el required del padre no alcanza a sus hijos. |
| Pones additionalProperties false y aun así pasan claves extra | Deja de funcionar en cuanto lo combinas con allOf o $ref. El motivo es que additionalProperties sólo mira las properties escritas en el mismo objeto de esquema. Hereda un esquema base mediante allOf y pon additionalProperties: false en el hijo, y hasta las propiedades que definió la base cuentan como adicionales, con lo que se rechazan datos perfectamente válidos. Ponlo en la base y se rechazan las propiedades que añade el hijo. Es donde más tiempo se evapora en JSON Schema, y usar herencia de esquemas lo vuelve casi inevitable. |
En 2019-09 en adelante, usa unevaluatedProperties: false. Descuenta las propiedades ya evaluadas por allOf y $ref antes de juzgar, así que se lleva bien con la herencia: es la palabra clave que se añadió precisamente para esto. Si tienes que quedarte en Draft 7, quitar la herencia y aplanar el esquema en un solo documento al empaquetar es más rápido. Aparte, que una API deba rechazar claves desconocidas es una decisión de diseño: rechazarlas te cuesta la compatibilidad hacia delante y añadir un campo rompe a todos los clientes existentes. Estricto a la entrada y tolerante a la salida (el principio de Postel) es el valor seguro. |
Escribe siempre $schema. Si lo omites, la implementación elige un draft por defecto y el mismo esquema significa cosas distintas en sitios distintos. Draft 7 y 2020-12 difieren especialmente en las palabras clave de array: las tuplas —arrays cuyas posiciones tienen tipos distintos— pasaron de la forma de array de items a prefixItems, y darle sintaxis de tupla de Draft 7 a una implementación 2020-12 aplica el primer tipo a todos los elementos del array. No se lanza error; sólo cambia el significado, en silencio. Y una cosa más: no te fíes de unos datos sólo porque validaron. JSON Schema garantiza la forma, y la coherencia de negocio — si ese identificador existe, si las líneas suman el total — queda fuera de su alcance. La validación de esquema es un filtro en la puerta, no un sustituto de la validación de dominio.
📖 Cómo usar
-
1
Ingresa el JSON SchemaPega tu JSON Schema en el panel izquierdo.
-
2
Ingresa los datos JSONPega los datos JSON en el panel derecho.
-
3
Revisa los errores y corrigeLos errores muestran ruta, mensaje y parámetros.
❓ Preguntas frecuentes
¿Qué versiones Draft soporta?
¿Funciona la validación de format?
¿Qué es JSON Schema?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.