JSON to Zod schema

TypeScript interfaces vanish at compile time. The moment an API drops a field, renames a key or sends a string where you expected a number, your app blows up at the use site with a mysterious "undefined is not a function".

A Zod schema validates the payload at the boundary — once, right after the fetch() — and either narrows the type or throws a precise error pointing at the bad field. You get the static type for free via z.infer<typeof schema>.

1. Parse the JSON via JSON.parse.
2. Walk the tree producing a "shape" for each value — primitive, array, object or union.
3. Merge sibling shapes (array elements, objects with overlapping key sets). Missing keys become .optional(). null + T becomes T.nullable(). Multiple non-null types become z.union([...]).
4. Emit a single z.object({...}) tree as plain TypeScript source.

Sample data tells us the shape, not the rules. After generating the baseline schema, add semantic refinements as needed:

• .email(), .url(), .uuid() on strings that follow well-known formats.
• .min(n) / .max(n) on lengths, counts and bounded numbers.
• .regex(/^…$/) for IDs, phone numbers, postcodes.
• z.enum([...]) for status fields where you know the closed set of values.
• z.date() + .transform() when your wire format is an ISO string but you want a JS Date.

• Paste multiple records when you can. A single sample marks every field required. Two samples with differing keys mark the difference .optional().
• Mind numeric IDs. JSON has no int vs string distinction; phone numbers, postal codes and snowflake IDs are often JSON numbers but should be z.string() to preserve leading zeros and avoid precision loss above 2⁵³.
• Use .passthrough() sparingly. Without it, Zod silently drops unknown keys on parse — that's usually what you want. Switch it on only if you're proxying a payload through unchanged.

Use this tool for quick inspection, cleanup, conversion, and copy-paste debugging. Use your IDE formatter, schema tests, or CI checks when the same rule needs to be enforced across a repository.

• Validate the output before committing it, especially when fixing almost-valid input.
• Escaping, comments, trailing commas, and mixed encodings are the usual source of surprising results.
• For production config, keep a copy of the original until the consuming system accepts the rewritten file.