Validador de JSON Schema

Cómo usar

1. Pega el esquema en el primer recuadro y el documento que quieres comprobar en el segundo. Ambos se guardan, así que puedes cerrar la página y volver.
2. Mira las fichas del resumen: válido o no, cuántos errores, qué draft se usó y el tamaño del documento. La línea del draft dice también si vino del $schema o del selector.
3. Recorre las filas de error. Cada una da el JSON Pointer, la línea de tu documento, la palabra clave que falló, el valor que había y el sitio dentro del esquema, para que puedas arreglar cualquiera de los dos lados.
4. Abre una fila de anyOf o oneOf y lee las ramas. La marcada como la más cercana es la que falló en menos cosas, que suele ser la que buscabas.
5. Activa "Comprobar format" cuando quieras que format falle en vez de anotar: viene apagado porque la especificación lo define como anotación y la mayoría de validadores lo dejan así.

Preguntas frecuentes

¿Por qué pasa mi documento si esperaba que fallara?

Casi siempre porque el esquema dice menos de lo que parece. JSON Schema ignora las palabras clave que no conoce, así que "require" en vez de "required", "minlength" en vez de "minLength" o una palabra de 2020-12 dentro de un esquema draft-07 no son un error: son una anotación que no hace nada. Los objetos además aceptan propiedades extra salvo que additionalProperties o unevaluatedProperties lo impida, los arrays aceptan cualquier cosa si no hay items ni prefixItems, y format solo anota hasta que activas la comprobación. Mira también el draft de las fichas: una palabra clave puede existir en un draft y no en otro, y aquí se ignora la que el draft elegido nunca tuvo.

¿1.0 es un entero?

Desde draft 6, sí: la especificación define "integer" por el valor, así que 1.0 y 1.0e2 son enteros y 1.5 no. En draft 4, no: un número escrito con parte decimal es un float y falla "type": "integer". Esta herramienta conserva cómo estaba escrito cada número al analizarlo, que es lo único que permite distinguir 1 de 1.0, porque JSON.parse da el mismo valor para ambos. Si validas con una librería antigua contra un esquema draft-04, esa diferencia causa sorpresas reales en producción, y cambiando el selector de draft aquí la reproduces.

¿Por qué 0.3 no es múltiplo de 0.1?

Porque ninguno de los dos números es exacto en coma flotante binaria. 0.3 dividido entre 0.1 da 2.9999999999999996, no 3, y los validadores de referencia comprueban justo ese cociente, así que rechazan el documento. El mismo esquema escrito como "multipleOf": 1 con el valor escalado a 3 pasa sin problema. No es una manía de esta herramienta: python-jsonschema, ajv y los demás se comportan igual con un multipleOf decimal, por eso un esquema que quiere decir "dos decimales" se escribe mejor como pattern o como un entero de céntimos.

¿Cómo se lee el JSON Pointer de un error?

Un puntero es una ruta de tokens separados por barras desde la raíz del documento: /server/port es el miembro port del objeto server y /tags/2 es el tercer elemento de tags, porque los índices empiezan en cero. Un puntero vacío significa el documento entero, y por eso los errores de required, additionalProperties o uniqueItems apuntan al objeto o al array que los contiene y no al miembro: la propiedad que falta no tiene sitio propio. Una barra dentro de un nombre de propiedad se escribe ~1 y una virgulilla ~0. El número de línea junto al puntero es esta herramienta resolviendo esa ruta en el texto exacto que pegaste.

¿Por qué otros validadores sacan tantos errores con anyOf?

Porque un anyOf fallido falló de verdad en todas las ramas y todos esos errores son ciertos. Un validador sin criterio los imprime uno detrás de otro, así que una unión de cadena y objeto acaba en una lista donde "no es de tipo string" convive con una queja por una propiedad ausente de un objeto que nunca quisiste. Agruparlos por rama devuelve la estructura que el esquema ya tenía, y elegir la rama con menos fallos te lleva a la buena casi siempre. Es una heurística, no una prueba: si dos ramas fallan en una cosa cada una, se marca la primera, y el esquema no puede decir cuál pretendías.

¿Puede seguir un $ref a otro archivo o a una URL?

No, y es deliberado: aquí nada toca la red, así que un $ref a https://example.com/user.json, o a un archivo vecino como common.json#/$defs/id, no se puede resolver y se informa como fallo del esquema en lugar de ignorarse en silencio. Las referencias dentro del texto pegado funcionan por completo: #/$defs/name, un # a secas, una referencia recursiva a la raíz, un $anchor y un $id al que apunte otra referencia. Para comprobar un esquema repartido en archivos, empaquétalo antes: pega las definiciones en $defs y reapunta las referencias, que es lo que hace casi todo el tooling antes de publicar un esquema.

Herramientas relacionadas