Conversor JSON Schema ⇄ Zod

En la entrada. JSON to Zod deduce los tipos a partir de un valor de ejemplo, como una respuesta de API, así que no puede saber qué campos son obligatorios ni qué formatos de cadena se aplican. Esta herramienta parte del propio JSON Schema, de modo que restricciones como required, enum, minLength y format:email se trasladan a la cadena de Zod (.optional() / .enum() / .min() / .email()). Si ya tiene una definición OpenAPI o JSON Schema, esta es la vía precisa.

Los valores por defecto están invertidos. JSON Schema considera obligatoria una propiedad solo si aparece en el array required, mientras que Zod la considera obligatoria salvo que lleve .optional(). El conversor absorbe esa diferencia: hacia Zod, las propiedades ausentes de required reciben .optional(); en sentido inverso, las que no llevan .optional() se recogen en el array required.

Las referencias no se resuelven: un $ref se convierte en z.any() y se muestra una advertencia. Si su esquema extrae definiciones comunes a $defs, incorpórelas antes de pegar o corrija esa parte a mano tras la generación. allOf también se advierte, porque aquí no puede expresarse una intersección: solo se convierte el primer subesquema.

Sirve como esqueleto, pero las reglas de negocio que nunca estuvieron en el JSON Schema —dominios de correo permitidos, coherencia entre campos— no aparecerán. Tenga en cuenta además que pattern se convierte en z.string().regex(), que puede comportarse de otro modo si la expresión regular original no es compatible con ECMAScript. Revise siempre el resultado.

La sección components.schemas de OpenAPI es JSON Schema, así que pegarla aquí le da un esquema de Zod y un tipo z.infer de una vez, evitando que el contrato del servidor y la validación del cliente se separen.

Si el esquema Zod llegó primero en su código, ejecute la conversión inversa para obtener JSON Schema y llevarlo a los components de OpenAPI o a su documentación.

Al sustituir un montón de sentencias if, un JSON Schema existente le da un punto de partida completo en Zod, con muchos menos campos obligatorios y enums olvidados.

Pegue el esquema que produjo un LLM y conviértalo en un esquema de Zod que realmente compile, obteniendo tipos estáticos y validación en tiempo de ejecución.

Un $ref no se resuelve y pasa a ser z.any(); de allOf solo se convierte el primer subesquema. if/then/else y not no están soportados. Todo ello se muestra como advertencia bajo el resultado para que complete esas partes a mano.

Para que todo ocurra en el navegador, el código nunca se ejecuta: se analiza como texto. Se admiten z.object / z.array / z.union / z.enum / z.literal / z.record y las cadenas de métodos habituales, pero un esquema referenciado mediante una variable, o una función arbitraria como .refine(), no puede representarse en JSON Schema y se ignora.

Un pattern de JSON Schema se convierte en z.string().regex(), y en sentido inverso su contenido vuelve a pattern. JSON Schema permite expresiones regulares no compatibles con ECMAScript, así que un traslado directo puede cambiar el comportamiento.

Esta herramienta produce un punto de partida para una migración. Las reglas de negocio y las comprobaciones de coherencia entre campos no se generan salvo que estuvieran en el esquema original; revise el resultado antes de usarlo en producción.