JSON to TypeScript & Zod.

What the generator infers

Every value in the sample collapses into one node that records which shapes were seen at that position, and then the nodes get merged. Array elements merge into a single element type, so [1, "a", true] becomes number | string | boolean rather than a tuple. When every element is an object, the keys are unioned and each one is counted: a key that appeared in two of three elements is marked optional. null is tracked as a modifier instead of a member, so a field that was sometimes a string and sometimes null comes out as string | null and .nullable(), not as a union containing null.

Strings are then probed for shapes worth validating — UUID, email, http(s) URL, YYYY-MM-DD, and ISO-8601 datetimes. Timezone handling is deliberately literal: a trailing Z emits z.iso.datetime(), a numeric offset emits z.iso.datetime({ offset: true }), and no timezone at all emits z.iso.datetime({ local: true }), because the default form rejects the other two. If one field mixes formats, the detector gives up and emits a plain z.string() — dropping to a looser type is never wrong, and a field with three date formats in it is a data problem you want to see, not paper over. Numbers get z.int() only when every sample was a whole number.

One sample under-specifies a schema

This is the thing every JSON-to-TypeScript tool quietly gets wrong, mine included, and there is no fixing it from the input side. A single response is one point on a distribution. It cannot tell you that coupon is absent for 98% of orders, that status is really one of four strings, that items is occasionally empty, or that discount: null is a number the rest of the time. Optionality and unions are properties of the set of possible payloads, and you handed the generator exactly one.

So change the input. Grab twenty real responses from your logs, wrap them in an array, and paste that. The merge does the work: keys that vary get the ?, fields that vary get a union, and you find out in ten seconds that a field you thought was string is string | number in production. Same trick for a paginated endpoint — paste the page of results, not one item.

Parse, don't validate

A TypeScript interface is a claim, not a check. JSON.parse returns any, and const user = await res.json() as User is a lie the compiler believes: it deletes the type error without deleting the bug. Everything downstream is now typed against a shape nobody verified, and the undefined is not an object lands four call frames away from the response that caused it.

Parse, don't validate means turning unknown input into a value whose type proves the checks already ran. That is what the Zod tab is for. const user = UserSchema.parse(await res.json()) either throws at the boundary with a path telling you which field was wrong, or hands back a value the type system and the runtime agree on. The z.infer line at the bottom of the output exists so the type is derived from the schema — write both by hand and they drift within a sprint.

Validate at boundaries, trust types inside

Runtime validation costs something, so spend it where data enters the system and nowhere else: HTTP responses from services you don't own, webhook bodies, queue messages, config files, environment variables, and the JSON an LLM produces for a tool call. Those are the places where the shape can be wrong at 3am. Inside your own module, between two functions you wrote, the compile-time type is enough — re-validating there is ceremony that buys nothing.

One Zod v4 detail worth knowing before you deploy the output: z.object() strips keys it doesn't know about. If you validate a webhook and then forward the parsed value onward, the fields you didn't model are gone. Use z.looseObject() when you re-serialize, and z.strictObject() when an unexpected key should be a loud failure.

Zod v4 syntax, not v3

Most generators on the web still emit Zod 3. The v3 method chains mostly keep working in v4, but they are deprecated, they are not tree-shakable, and one of them is now an outright type error — z.record() requires a key schema as well as a value schema. Here is the mapping this tool emits:

The Date option is the one place the two tabs deliberately disagree with the wire format. JSON has no date type, so the honest TypeScript type for a timestamp is string. Tick the box and you're saying the type describes the value after validation: the TypeScript side becomes Date, and the Zod side validates the ISO string first and then transforms it, which is stricter than coercing whatever the Date constructor happens to accept.

Where not to trust the output

Read the generated code as a draft written by something that saw one example. In particular:

• Enums are invisible. "status": "paid" gives you string. If it is really "paid" | "pending" | "refunded", only you know that.
• Big integers. JSON numbers are IEEE-754 doubles. A 64-bit id past 2^53 has already lost precision by the time JSON.parse returns, and z.int() only asserts the safe-integer range — it cannot recover what the parse threw away. Ask the API for a string.
• Optional and nullable are different bugs. A missing key and a null key fail in different places. The selector above exists because plenty of APIs do both, inconsistently, on the same field.
• Semantics never survive. z.email() checks a shape, not a mailbox. A number field that must be positive, a string with a max length, two fields that have to agree — all of that is .min(), .max() and .refine() you add by hand.
• Empty containers say nothing. [] becomes unknown[] and {} becomes Record<string, unknown>, because that is genuinely all the sample proves. Same for a key that was null every time: you get the null type and a chip in the stats line saying so. Go find a payload where they aren't empty.