JSON to Types
Infer TypeScript interfaces, Zod schemas or PHP DTOs from a JSON sample, with nested and array shapes named and deduplicated, live in your browser.
Generated files
Generated files appear here.
Diagnostics appear here after you paste your input.
Processed locally in your browser. Your data never leaves your device.
About this JSON to types converter
Paste a JSON sample and get TypeScript interfaces, Zod schemas or PHP DTOs: one named type per object shape in the document, arrays and nested objects handled recursively, and optional and nullable fields kept distinct. It reads real samples rather than asking for a JSON Schema, so it works directly from an API response, a log line or a fixture file.
How to use it
- Paste a JSON value, drop a file, or load an example.
- Choose an output (TypeScript, Zod or PHP) in the Output menu.
- Set a root type name if you want one other than "Root".
- Read the diagnostics: they explain unions, always-null fields and anything sampled or truncated.
- Copy or download each file, or download them all as one ZIP.
What gets inferred
- An array of objects is treated as a set of samples: fields are merged across every element, so the result reflects the whole array, not just the first item.
- Nested objects (and objects inside arrays) become their own named type, and two structurally identical shapes anywhere in the document share one type.
- A field that disagrees between samples becomes a union of the types actually seen, never a guess at the "real" type.
- Property names that are not valid identifiers (such as
first-name) are kept exactly, quoted where the target language requires it.
TypeScript, Zod and PHP side by side
The same field, generated three ways:
// TypeScript
nickname?: string
// Zod
nickname: z.string().optional()
// PHP
public ?string $nickname = nullZod schemas also export the equivalent TypeScript type (z.infer) next to each schema by default, so a Zod schema alone often replaces both files. PHP DTOs add explicit fromArray/toArray methods so the mapping between a JSON key and a PHP property is always visible in code, never left to a naming convention.
Frequently asked questions
- How does it decide a field is optional, or nullable, or both?
- When the JSON is an array of objects, every element is a sample. A field present with a value in every sample is required. A field present but sometimes null becomes nullable (a union with null in TypeScript/Zod; a `?`-prefixed type in PHP). A field missing from at least one sample becomes optional, whether or not it was ever seen as null. The two are tracked separately and can combine.
- What happens when a field has different types in different samples?
- It becomes a union: `number | string` in TypeScript, `z.union([z.number(), z.string()])` in Zod, `int|float|string` in PHP (a real union type, not a guess). Nothing is silently coerced to one type or the other.
- Why do nested objects get their own named type?
- Every object shape in the JSON becomes its own interface, schema or class, named after the key or array field that held it (an array of "posts" produces a `Post` type). Two shapes that turn out to be structurally identical anywhere in the document share one type instead of being generated twice.
- Does it look at every element of a large array?
- Up to 500 elements; a larger array is sampled from the first 500 and a note says so. In practice this is enough for a field to reveal whether it is ever optional or ever a different type, without re-reading an enormous payload.
- Is my JSON uploaded?
- No. Inference and generation happen in your browser (large input in a background worker). Nothing is sent anywhere or stored.
- Which output should I use?
- TypeScript interfaces for compile-time types only. Zod schemas when you also need runtime validation (Zod includes the TypeScript type via `z.infer`, so you often only need Zod). PHP DTOs for a typed value object with explicit `fromArray`/`toArray` methods, useful at an API boundary in a PHP or Laravel backend.