Saltar al contenido
Conversión de esquemas

Conversor JSON Schema ⇄ Zod

Genere un esquema de Zod a partir de JSON Schema, o vuelva a escribir JSON Schema desde código Zod. Relaciona required con .optional(), además de enums, uniones, objetos anidados, formatos de cadena y restricciones de longitud en ambas direcciones. Lo que no se puede convertir se informa como advertencia. Todo se ejecuta en su navegador y el esquema que pega no se envía a ningún sitio.

Guía: Cómo usarlo y características

  • Elija «JSON Schema → Zod» y pegue un esquema para obtener una definición `z.object({ ... })` junto con un alias de tipo `z.infer`.
  • Elija «Zod → JSON Schema» para el sentido inverso. Las líneas `import` y `export const user =` no molestan: el analizador toma la expresión que empieza en `z.`.
  • Las propiedades ausentes de `required` reciben `.optional()`, y en sentido inverso todo lo que no lleve `.optional()` pasa a `required`.
  • Los detalles de cadena también se corresponden: `format: "email"` se convierte en `.email()` y `minLength` en `.min()`.
  • Lo que no se puede convertir, como `$ref` o `allOf`, aparece como advertencia bajo el resultado en lugar de generar en silencio una salida rota.

FAQ: Preguntas frecuentes

  • ¿En qué se diferencia de la herramienta JSON to 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.
  • ¿Cómo se corresponden required y .optional()?

    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.
  • ¿Admite esquemas que usan $ref?

    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.
  • ¿Puedo usar el esquema Zod generado para validar en producción?

    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.

Casos de uso: Casos de uso habituales

  • Convertir una definición OpenAPI en tipos y validación de front-end

    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.

  • Exportar un esquema Zod existente como contrato de API

    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.

  • Migrar validaciones escritas a mano a un enfoque basado en esquemas

    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.

  • Hacer utilizable un JSON Schema generado por IA

    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.

Notas: Notas y limitaciones

  • $ref, allOf y los condicionales no se expanden

    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.

  • Zod → JSON Schema analiza el código como texto

    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.

  • Las expresiones regulares de pattern se trasladan tal cual

    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.

  • Revise siempre el resultado generado

    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.

Artículos para esta herramienta

Articulos recientes

Introducción
2026-08-06

Convertir entre JSON Schema y Zod: cómo se corresponden required y .optional()

Por dentro de un conversor bidireccional que transforma JSON Schema en un esquema de Zod y el código Zod de vuelta a JSON Schema. Incluye los valores por defecto invertidos entre required y .optional(), la tabla de correspondencia de restricciones y cómo se analiza Zod sin ejecutar código.

Caso de uso
2026-08-06

Orden de evaluación en SQL: por qué WHERE no ve el alias del SELECT

El orden en que escribe las cláusulas de SQL no es el orden en que se ejecutan. Referencia del orden lógico (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT), por qué fallan los alias en WHERE, cuándo usar WHERE y cuándo HAVING, ONLY_FULL_GROUP_BY y la trampa de LEFT JOIN con WHERE.

Caso de uso
2026-08-06

Formato unified diff: cómo leer las cabeceras @@ de git diff

Cómo leer el formato unified diff que genera git: qué significan los cuatro números de @@ -12,7 +12,9 @@, por qué un cambio de un solo carácter aparece como línea completa reemplazada, las trampas de los espacios y los finales de línea, \ No newline at end of file, los diffs combinados @@@ en los merges y la detección de renombrados.

Caso de uso
2026-08-06

Conversión UTC⇄JST: tabla del desfase de 9 horas y errores de zona horaria

Convierta entre UTC y la hora de Japón (JST) con una tabla de referencia, y vea por qué la diferencia con España cambia entre 7 y 8 horas según el horario de verano. Incluye el significado de Z y +09:00 en ISO 8601, cuándo JavaScript desplaza las fechas, el comportamiento de MySQL/PostgreSQL y por qué el cron de GitHub Actions siempre corre en UTC.

Caso de uso
2026-08-04

Referencia de CREATE TABLE: tipos y restricciones en MySQL, PostgreSQL y SQLite

Referencia de CREATE TABLE (DDL) con tablas comparativas entre bases de datos: tipos de datos, autoincremento (AUTO_INCREMENT / IDENTITY / rowid), comportamiento de ON DELETE en claves foráneas y la restricción CHECK que MySQL ignora en silencio.

Introducción
2026-08-03

Cómo generar sentencias CREATE TABLE desde un diseño visual | Generador de DDL

Un vistazo al interior del Generador de DDL, que convierte un diseño visual de tablas en sentencias CREATE TABLE y un diagrama ER. Incluye las reglas de conversión de tipos para MySQL/PostgreSQL/SQLite y el algoritmo de inferencia de columnas desde JSON.

Anuncio

Anuncio