¿Por qué mi esquema generado rechaza datos válidos?

Casi siempre porque se marcaron todas las claves como obligatorias, o porque un campo que era null en la muestra se tipó como null en vez de admitir nulos. Ambos son artefactos de inferir desde un único documento y ambos hay que corregirlos a mano.

¿Cómo consigo un esquema que sirva de verdad?

Trata la salida como un primer borrador. Amplía a uniones los campos que admiten nulos, saca de required las claves realmente opcionales, añade format y enum donde conozcas la restricción, y valídalo contra varios documentos reales y no solo contra aquel del que lo generaste.

Generador de esquemas JSON

Pega JSON y genera un JSON Schema.

JSON de entrada

Todos los cálculos se realizan localmente en tu navegador. No se envía ningún dato al servidor.

Los resultados tienen carácter informativo. Contrástalos con otras fuentes.

Inferir un JSON Schema y lo que la inferencia no puede saber

Un esquema generado a partir de una muestra describe esa muestra, no tu modelo de datos. Acierta la forma y falla la intención, porque un único ejemplo no puede decir qué campos son opcionales, qué valores forman una enumeración y qué nulos tienen significado.

Cómo funciona

Recorre el JSON y emite un tipo para cada valor: objeto, array, cadena, número, booleano o nulo.
Marca como obligatoria toda clave presente en la muestra, porque es lo único que un ejemplo permite sostener.
Desciende de forma recursiva en objetos anidados e infiere los tipos de elementos de array a partir de lo que encuentra.

tipos inferidos
  "texto"     → string
  42          → number (integer si no hay decimales)
  true        → boolean
  null        → null   (no "opcional")
  [ ... ]     → array con elementos inferidos
  { ... }     → object con propiedades

required = toda clave vista en la muestra

Ejemplo resuelto

Inferencia a partir de {"id": 1, "name": "Ada", "email": null, "tags": ["a", "b"]}.

id → integer, name → string
email → null, lo que casi seguro está mal: debería ser ["string", "null"]
tags → array de cadenas
las cuatro claves marcadas como obligatorias
sin maxLength, sin format, sin enum: nada de eso se ve en una muestra

Un esquema estructuralmente correcto que rechazaría datos válidos. El campo email tipado como null solo acepta null, y marcar todas las claves como obligatorias rechaza cualquier registro al que le falte una.

Cómo leer el resultado

Un null en la muestra no significa que el tipo sea null. Casi siempre significa que el campo admite nulos, así que el tipo correcto es una unión como ["string", "null"]. La inferencia no puede distinguirlos y siempre adivina el más estrecho.
Todo acaba en required porque la ausencia es invisible. Aporta varios documentos distintos y la unión de claves revelará la forma real; con una sola muestra solo describes ese documento.
Los formatos, enumeraciones y límites son invisibles para la inferencia. Un correo, un UUID, una fecha y una cadena cualquiera se ven idénticos; añadir format, enum, minimum y maxLength es el trabajo que convierte una forma en un contrato.
Los arrays son la inferencia más débil. Un array vacío no da ningún tipo de elemento, y un array de tipos mezclados suele significar que la muestra no es representativa, no que el campo acepte cualquier cosa.

Preguntas frecuentes

¿Por qué mi esquema generado rechaza datos válidos?: Casi siempre porque se marcaron todas las claves como obligatorias, o porque un campo que era null en la muestra se tipó como null en vez de admitir nulos. Ambos son artefactos de inferir desde un único documento y ambos hay que corregirlos a mano.
¿Cómo consigo un esquema que sirva de verdad?: Trata la salida como un primer borrador. Amplía a uniones los campos que admiten nulos, saca de required las claves realmente opcionales, añade format y enum donde conozcas la restricción, y valídalo contra varios documentos reales y no solo contra aquel del que lo generaste.

Fuentes

JSON Schema Specification