How to convert JSON to Zod and validate API data

TypeScript interfaces disappear once the code is compiled. If an API starts returning a field in a different shape, or stops sending a field, your application only finds out when it breaks. Zod fixes that: you describe the expected shape in a schema, and it checks the real data as it arrives.

Writing schemas by hand for large responses is tedious. Converting a sample JSON into a Zod schema gives you the structure ready to refine.

1. Open Transform and choose JSON → Zod.
2. Paste a JSON representative of the response you want to validate.
3. Adjust the Root name (here, User) and click Transform.
4. Install the library with npm install zod, import z, and paste in the generated schemas.

The tool's real input and output:

{
  "id": 1,
  "name": "Ana Souza",
  "email": "ana@example.com",
  "active": true,
  "tags": ["admin", "beta"],
  "address": { "city": "São Paulo", "zip": "01310-100" }
}

const addressSchema = z.object({
  city: z.string(),
  zip: z.string(),
});

const userSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
  active: z.boolean(),
  tags: z.array(z.string()),
  address: addressSchema,
});

Nested objects become separate schemas (addressSchema) that the main schema reuses, which keeps the code organized and easy to reuse.

import { z } from "zod";

// ... schemas generated by the tool ...

// The TypeScript type comes straight from the schema, no interface to write by hand.
type User = z.infer<typeof userSchema>;

const response = await fetch("/api/users/1");
const result = userSchema.safeParse(await response.json());

if (!result.success) {
  console.error("Response doesn't match the expected shape:", result.error.issues);
} else {
  console.log(result.data.name); // the data has already been validated here
}

Prefer safeParse when you want to handle the error without throwing: it returns an object with success and, on failure, the list of problems found and which field they're in.

The tool infers basic types from the example: text becomes z.string(), numbers become z.number(), and so on. More specific rules are up to you:

const userSchema = z.object({
  id: z.number().int().positive(),
  name: z.string().min(1),
  email: z.string().email(),
  active: z.boolean(),
  tags: z.array(z.string()),
  nickname: z.string().optional(),     // may be missing from the response
  lastLogin: z.string().nullable(),    // may come back as null
});

If you already wrote the types, use the TypeScript → Zod conversion: paste the interface and get the equivalent schema back, without going through a sample JSON. Unlike inferring from JSON, here the tool sees what the types actually say, so it preserves optional fields, nullable values and literal-value unions:

type Role = "admin" | "user";

interface User {
  id: number;
  name: string;
  email?: string;
  role: Role;
  nickname: string | null;
}

const userSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().optional(),
  role: z.enum(["admin", "user"]),
  nickname: z.string().nullable(),
});

• email?: string became .optional().
• "admin" | "user" became z.enum([...]), even going through the Role alias.
• string | null became .nullable().

More advanced types (generics, Partial, Record, tuples, intersections with &, and the Date type) still come out simplified as z.unknown(); review the result in those cases.

• Just types: for data that originates inside your own application and that you control.
• Zod: at every boundary with the outside world, like API responses, forms, uploaded files, environment variables, and localStorage content.