JSON to Zod

Generate a Zod schema (<code>z.object</code>, <code>z.array</code>, <code>z.string</code>, <code>z.number</code>, <code>z.boolean</code>, <code>z.null</code>, <code>z.union</code>) from a JSON sample. Handles deep nesting, optional fields, and union types via array inspection. Pairs with TypeScript's <code>z.infer</code> for runtime-validated, typed data flow.

Why Zod won

TypeScript types are erased at runtime. The moment data crosses a system boundary — fetch response, form input, queue message — types stop helping. Zod fills the gap: a single schema is both runtime validator AND TypeScript type. Define once, use everywhere, get safety on both sides.

const User = z.object({
  id: z.number(),
  email: z.string().email(),
  name: z.string(),
  tags: z.array(z.string()).optional(),
});

type User = z.infer<typeof User>;
const user: User = User.parse(apiResponse);  // throws if invalid

The generator infers the schema from data. Manual refinement (.email(), .url(), .uuid()) you add by hand based on knowledge the JSON cannot reveal.

Common workflows

Validate API responses. Generate schema from a sample, save in src/schemas/, parse responses through it. Bad API → loud error, not silent data corruption.

Validate form input. Generate schema from the expected shape, layer on .email(), .min(), .refine() constraints. Hook into React Hook Form.

Generate types for an external API. Skip the manual interface authoring. Generate, refine, infer.

Migrate from JSON Schema. If you have JSON Schema, this tool produces equivalent Zod, often more readable.

When Zod isn’t right

For very large schemas, Zod runtime cost adds up. For schemas you control end-to-end (internal RPC), TypeScript types alone may be enough. For protocol-level validation (gRPC, GraphQL), use the protocol’s own type system.

Last updated: 2025-01-15