JSON to TypeScript

What a JSON to TypeScript converter does for your project

A JSON to TypeScript converter turns a sample payload into the typed interfaces your code needs the moment external data arrives. Whether it comes from a REST endpoint, a webhook, a database row, a config file or a model response, the safest move is to describe the shape explicitly and let the compiler catch every silent rename, missing field and wrong primitive. Writing those interfaces by hand for a two hundred line payload is slow and error-prone. This tool parses the JSON in your browser, walks the object tree and produces a clean baseline you refine instead of starting from nothing. Nested objects become separate named interfaces, homogeneous arrays become typed arrays, and mixed arrays become unions.

How the inference works

The conversion runs in four steps. First it parses the input with JSON.parse to confirm it is valid and to build the object graph in memory. Second it walks that graph and attaches a path to each value, so generated interfaces are named after their place in the tree. Third it maps each value to a TypeScript type: a primitive, a literal when you opt in, an inline shape for objects, or a union for mixed arrays. Fourth it deduplicates structurally identical objects so two array elements with the same fields share one interface, then renders the file with consistent indentation, optional readonly markers, and either interface or type syntax.

Common use cases

• Wrapping a third-party REST API. Paste a sample response, get the interface, drop it into your client, and refine optional fields once you have read the docs.
• LLM structured output. When you ask a model for JSON, a TypeScript interface is the cleanest contract. Generate it from a representative sample and reuse it as a Zod schema source.
• Webhook payloads. Stripe, GitHub and Slack publish example events. Converting them to interfaces makes your handler safe and documents the expected shape in code.
• Migrating JavaScript to TypeScript. The slowest part of a port is typing legacy data structures. This turns it into a paste-and-edit task instead of a typing marathon.

Limitations and review tips

A converter that sees one example cannot know which fields are truly required across the whole API. If the sample contains a middle name, the converter assumes it is always present. Run the tool on two or three representative samples, or cross-check the documentation, and add a question mark to fields you know can be absent. The same caution applies to literal types: a role of admin looks like a fixed set, but the API may also return manager or viewer. For runtime safety, pair the generated interface with a schema library like Zod, Valibot or ArkType so data from the network is checked against the same shape the compiler enforces.

Frequently asked questions

Why does the converter sometimes mark a field as optional?

If a field is null in the sample, or if it appears in some objects of an array but not in others, the converter marks it optional with a question mark by default. You can switch the behaviour to T or null in the options to keep the field required while still allowing a null value, or keep it as a literal null instead.

How does it handle arrays of mixed types?

Arrays of one primitive become string[], number[] or boolean[]. Arrays of mixed primitives become a union such as (string or number)[]. Arrays of objects that share the same keys collapse into a single generated interface, so the array becomes User[] rather than the same inline shape repeated for every element.

Is my JSON sent to a server?

No. The converter is fully client-side. Your JSON is parsed by the browser with JSON.parse and every interface is inferred in memory. Nothing is uploaded, logged or sent to an analytics endpoint, so you can paste production payloads, customer data or unreleased schemas safely.

Should I pick interface or type for the output?

For shapes that may be extended or merged across declaration files, prefer interface. For unions, intersections or mapped types, type is the better fit. The Style dropdown supports both and the result is structurally equivalent, so the honest answer is to match whatever your codebase already uses.