Skip to content

JSON to TypeScript & Zod

Paste JSON (like an API response) and get TypeScript interfaces or a Zod schema in one click. Nested objects, arrays, optional fields and nulls are all handled, and everything runs in your browser.
export interface Params {
  latitude: string;
}

export interface Endpoint {
  path: string;
  method: string;
  params?: Params;
  deprecated?: boolean;
}

export interface ApiResponse {
  id: number;
  name: string;
  rating: number;
  free: boolean;
  tags: string[];
  owner: null;
  endpoints: Endpoint[];
}

Types are inferred from this sample: fields missing from some array items become optional. Runs in your browser.

How the types are generated

JSONTypeScriptZod
"text"stringz.string()
42numberz.number().int()
4.8numberz.number()
truebooleanz.boolean()
nullnullz.null() / .nullable()
[…]T[]z.array(…)
{…}a named interfacea named z.object(…)
key missing in some array itemskey?:.optional()

Validate API responses with Zod

Generate a schema from a real response, then parse every response through it:

TypeScript
import { ApiResponseSchema } from "./schemas";

const res = await fetch("https://api.example.com/v1/items/42");
const data = ApiResponseSchema.parse(await res.json()); // throws if the shape is wrong
// data is fully typed from here on

Need a response to start from? Pick any free API that needs no key, or convert its curl example with the cURL converter. Messy JSON? Clean it up first with the JSON formatter.

Frequently asked questions

How do I convert JSON to a TypeScript interface?

Paste the JSON above. Every object becomes an interface named after its key (users becomes User), arrays become typed arrays, and nested objects get their own interfaces. Copy the result into a .ts file.

Should I use interface or type?

Either works for API data. Interfaces can be extended and merged and give clearer error messages; type aliases can express unions and mapped types. Pick whichever your codebase already uses.

Why use a Zod schema instead of just a TypeScript type?

TypeScript types disappear at runtime, so they can't stop an API from returning unexpected data. A Zod schema validates the response when it arrives and gives you the TypeScript type for free with z.infer, so a changed API fails loudly instead of causing undefined errors later.

How are optional fields detected?

From the sample. When an array contains objects, the converter merges them: a key that appears in some items but not others is marked optional (? in TypeScript, .optional() in Zod). Paste a response with several items for the most accurate types.

What can't be inferred from a JSON sample?

Dates (they're strings in JSON), enums (a field that's always 'GET' or 'POST'), and fields that weren't in your sample. Review the output and tighten types where you know more than the sample shows.

More free developer tools