JSON Schema ⇄ Zod Converter

The input is different. JSON to Zod infers types from a sample value such as an API response, so it cannot know which fields are required or what string formats apply. This tool takes JSON Schema itself, so constraints like required, enum, minLength and format:email carry through into the Zod chain (.optional() / .enum() / .min() / .email()). If you already have an OpenAPI or JSON Schema definition, this is the accurate path.

The defaults are inverted between the two. JSON Schema treats a property as required only when it is listed in the required array, whereas Zod treats a property as required unless it carries .optional(). The converter absorbs that: going to Zod, properties missing from required get .optional(); coming back, properties without .optional() are collected into the required array.

References are not resolved. A $ref becomes z.any() and a warning is shown. If your schema factors shared definitions into $defs, either inline them before pasting or fix up that part of the generated output by hand. allOf is also reported, because an intersection cannot be expressed here — only the first subschema is converted.

It works as a skeleton, but business rules that were never in the JSON Schema — allowed email domains, cross-field consistency — will not appear. Also note that a pattern becomes z.string().regex(), which can behave differently if the original regular expression is not ECMAScript-compatible. Always review the output before shipping it.

The components.schemas section of OpenAPI is JSON Schema, so pasting it here gives you a Zod schema plus a z.infer type in one step — and keeps the server contract and client validation from drifting apart.

If the Zod schema came first in your codebase, run the conversion the other way to produce JSON Schema you can drop into OpenAPI components or your docs.

When replacing a pile of if statements, an existing JSON Schema gives you a complete starting Zod schema — far fewer missed required fields and enums.

Paste a schema produced by an LLM and convert it into a Zod schema that actually compiles, giving you both static types and runtime validation.

A $ref is not resolved and becomes z.any(); allOf converts only its first subschema. if/then/else and not are unsupported. All of these are surfaced as warnings under the output so you can fill in those parts by hand.

To keep everything in the browser, the code is never executed — it is parsed as text. z.object / z.array / z.union / z.enum / z.literal / z.record and the common method chains are supported, but a schema referenced through a variable, or an arbitrary function such as .refine(), cannot be represented in JSON Schema and is ignored.

A JSON Schema pattern becomes z.string().regex(), and the reverse puts the source back into pattern. JSON Schema permits regular expressions that are not ECMAScript-compatible, so a direct move can change behaviour.

This tool produces a starting point for a migration. Business rules and cross-field consistency checks are not generated unless they were expressed in the original schema, so review the result before relying on it in production.