Skip to content
ToolBoxGenie

JSON to TypeScript Generator

Developer Tools · Added 18 August 2026

Paste an API response and get the TypeScript that describes it. Objects that appear in several places are emitted once and reused, fields missing from some array items become optional, and the result panel says plainly what a single sample cannot tell you — which is the part most generators leave you to discover in production.

Paste a real response. It is parsed in your browser and never uploaded.

How to use the json to typescript generator

  1. 1Paste a JSON sample — a real API response works better than a hand-written one.
  2. 2Name the root type after what it represents, such as UserResponse.
  3. 3Choose interface or type alias, and whether declarations should be exported.
  4. 4Turn on string literal unions if repeated string values represent a fixed set, such as a status field.
  5. 5Press Generate, then read the notes about what the sample could not determine.

Examples

A nested response

Input
{ "id": 1, "owner": { "name": "Ada", "email": "ada@example.com" } }
Result
interface Root with id: number and owner: Owner, plus a separate Owner interface

An array whose items disagree

Input
[{ "env": "prod", "healthy": true }, { "env": "staging", "healthy": false, "note": "flaky" }]
Result
note?: string — optional, because it is absent from one of the items

Literal unions

Input
Three objects whose status field is "active", "paused" and "active"
Result
status: "active" | "paused" when literal inference is on, instead of string

About the json to typescript generator

Types from a sample, and the limits of that

Generating types from JSON is inference from one observation. It is genuinely useful — it saves a tedious half hour and it catches structure you would have missed reading the response by eye — but everything it produces is a hypothesis about the API, not a description of it.

The failure mode worth naming: a generated type that marks every field required gives you a compiler that confidently enforces a contract the server never agreed to. The code type-checks, ships, and throws at runtime the first time a field is omitted. Generating optional fields where the sample disagrees, and flagging what the sample cannot answer, is the difference between a useful draft and a false sense of safety.

How shapes are merged

Every element of an array is described separately and then unified. Objects with matching shapes fuse into one type; objects that differ produce a merged type with the differing fields marked optional; genuinely different kinds of value produce a union.

Identical shapes appearing at different points in the document are emitted once and referenced by name, which is what a person writing the types by hand would do. The naming follows the key that introduced the shape, singularised when the key is plural — a deployments array yields a Deployment interface.

Where to go from the draft

Two habits make generated types pull their weight. First, keep them in the repository rather than regenerating on demand: when the API changes, the diff tells you what changed, which is information you cannot get any other way without reading a changelog.

Second, validate at the boundary. TypeScript types are erased at compile time and enforce nothing at runtime, so a response that does not match produces no error at the point where it entered your program — it produces one much later, somewhere confusing. A runtime schema check where the data arrives turns that into an error message that names the field.

Frequently asked questions

Why is a field optional when it is present in my sample?
Because it was absent from at least one other object in the same array. That is exactly what optional means for an API response — sometimes there, sometimes not — and inferring it from the disagreement between array items is more useful than typing every field as required. If a field is genuinely always present and just happened to be missing from one item in your sample, remove the question mark by hand.
Why does a null field become unknown | null?
Because a sample containing null tells you the field can be null and nothing at all about what it is when it is not. The honest type is a union with unknown, and the result panel flags it so you go and look at the documentation rather than accepting a type that compiles but means nothing. Turn the option off and you get the literal null type instead.
What about an empty array?
It becomes unknown[], and that is flagged too. An empty array is genuinely uninformative about its element type — the only fix is a sample that includes at least one item. Guessing would produce a type the compiler enforces and reality ignores.
It warned about a large number. Why?
JavaScript numbers lose precision above 2^53, so a 19-digit database ID has already been rounded by JSON.parse before this tool ever sees it. The value in your output may not be the value the server sent. Large identifiers should be strings on the wire for exactly this reason, and if you control the API, that is the fix.
Should I use these types as-is?
As a first draft. They describe the sample, not the contract — a generator cannot know that a field is nullable, that an enum has a fifth value you did not see, or that an array is sometimes absent rather than empty. Check the output against the API documentation, then keep the types in version control so a change in the response shows up as a diff.
Does anything get sent to a server?
No. Parsing and generation both happen in your browser, which is the point — pasting a production API response into someone else's server is how tokens and customer data end up in logs you do not control.

Related tools