From raw JSON payload to real TypeScript types

You know the drill: an API returns a fat JSON payload, and now you need TypeScript types for it. Writing interfaces by hand is tedious and error-prone — miss one nested object and the compiler only complains weeks later, in production-adjacent code. Inferring the types directly from a real response gives you a truthful starting point in seconds.

Good inference is more than wrapping every object in an interface. Arrays rarely contain one clean shape: some items skip keys, others add nulls, and the same nested structure shows up in five places. A serious generator merges array item shapes into one interface, marks half-present keys optional, deduplicates identical structures into a single shared declaration, and does it all deterministically — the same input always produces byte-for-byte the same output.

Open the free JSON to TypeScript — no signup, runs entirely in your browser.

How to use it

1. Paste your JSON payload — an API response, config file or fixture — into the input panel.
2. Set the root name (it becomes the top-level interface or type alias) and pick your options.
3. Read the generated TypeScript, then copy it straight into your codebase with one click.

Why this one

• Array items merge into a single interface; keys missing from some items become optional, or required with | undefined if you prefer strictness.
• Mixed arrays produce honest union types like (UserItem | string)[] instead of silently picking a winner.
• Structurally identical objects dedupe into one shared interface, named after its first occurrence.
• Null handling is precise: always-null fields type as null, sometimes-null fields gain a | null union member.
• Runs entirely in your browser — the payload you paste never leaves your device.

Frequently asked questions

How are interfaces named?

Names follow the key path: a nested object under user becomes RootUser, its address becomes RootUserAddress, and objects inside an array get a mechanical Item suffix — users becomes RootUsersItem, never singularized. If two different shapes sanitize to the same name, later ones get numeric suffixes, so output stays valid and deterministic.

What happens when array items have different keys?

Their shapes merge: a key present in every item stays required, while a key missing from some items becomes optional (marked with ?). Toggle the option off and those keys stay required with undefined appended to their type union instead — useful when you want the compiler to force explicit handling.

Can it handle null values and mixed-type arrays?

Yes. A field that is null in every item types as null; one that is null only sometimes gains | null in its union. Arrays mixing objects and primitives merge the objects into one interface and add the primitives as union members, producing types like (RootItemsItem | string)[].

Why are identical nested objects declared only once?

The generator compares canonical structural signatures — the sorted set of keys and their resolved types. When two objects match, the first-seen interface name wins and every occurrence references it. That keeps the output small and makes later refactors touch one declaration instead of five copies.

Is the generated output stable enough for snapshots?

Yes — generation is fully deterministic. Union members follow a fixed order, declarations emit in first-seen order, keys keep their JSON order, and identical input always yields byte-for-byte identical output, which makes it safe for snapshot tests and code review diffs.