JSON to TypeScript Type Converter

Paste a JSON object (or JSON array) to automatically generate the corresponding TypeScript interface/type definitions.

Generating TypeScript types from JSON

The first thing you need when consuming an API response in TypeScript is a type definition. Writing an `interface` by hand while squinting at deeply nested JSON is laborious, and **it is precisely the kind of work where a property gets missed or a type gets mistaken.** Paste the JSON here and this tool generates the matching `interface` or `type` for you.

The generator infers TypeScript types from the JavaScript types of the values. **Nested objects are lifted out as separate interfaces**, and arrays take the type of their elements as `T[]`. You can name the root type freely, so the output pastes straight into your project. **Because the inference rests entirely on the sample you paste, properties that may be omitted and fields that may be null are things you must add afterwards** with `?` or a union. Everything runs in your browser.

How to generate the types

  1. Paste the JSON Enter a sample API response as it stands. An object or an array both work.
  2. Name the root type This becomes the name of the top-level interface. The default is fine if you have no preference.
  3. Review the output Nested objects appear lifted out as separate interfaces.
  4. Add the optional fields yourself **Anything absent from the sample cannot be inferred.** Add `?` and `| null` where they belong.
  5. Copy it into your project The result pastes directly into a `.ts` file.

Tips for getting more out of it

  • When all elements of an array are objects, their keys are merged into a single interface. Keys missing from some elements are automatically treated as optional (`?`).
  • The root type name defaults to "Root", but you can rename it to anything you like (e.g. `User`, `ApiResponse`). Interface names for nested objects are generated automatically from their property names.
  • Paste a sample JSON response from your API as-is to quickly get a starting point for the type definitions used in your frontend code.
  • The generated output is only a first draft inferred from structure. We recommend reviewing it manually against your actual API spec (nullable fields, required fields, etc.) before relying on it.

Where this helps

Typing an external API

Even where an API ships no type definitions, a sample response gives you a starting point.

Typing an existing JSON config file

When you want to read a configuration file type-safely, the structure drops straight into a type.

Deriving types from mock data

Building the front end first, you can produce types from provisional data.

Checking a hand-written type

Compare a type you wrote yourself against the generated one to find what is missing.

TypeScript terms explained

interface
A declaration describing the shape of an object. **Declaring the same name more than once merges them automatically**, which is what distinguishes it from a type alias.
Type alias
A declaration giving a name to any type. It can name unions and primitives too, which an interface cannot.
Optional property
A field marked with `?`, as in `name?: string`. **It cannot be inferred from a pasted sample.**
Union type
A type such as `string | null`, expressing that a value may be any one of several types.
Nested object
A structure whose value is itself an object. This tool lifts it out as a separate interface.
Type inference
Deriving a type from a value. **The inference here rests on the single sample you paste, which is not necessarily the API's actual specification.**

Frequently asked questions

Writing type definitions by hand from a sample API response is time-consuming and error-prone — it's easy to mistype a key name or miss a type. Auto-generating them saves frontend developers a lot of time and helps avoid these mistakes.

The keys of every element in the array are merged; keys that only appear on some elements automatically become optional properties (`?`). If the same key has different types across elements, it's represented as a union type (e.g. `string | number`).

The generated definitions are mechanically inferred from the structure of the sample JSON alone. Things like whether a field is nullable or might be added in the future can't be determined from sample data alone, so we recommend checking them against your API documentation and adjusting manually.

The interface name for a nested object is automatically generated from the property key that holds it (e.g. an object under a `profile` key becomes an interface named `Profile`). If a differently-shaped interface with the same name is needed, a number is appended to distinguish them.
Tool-kun

Side Note — The "Type Drift" Problem That Type-Inference Tools Solve

TypeScript is a language that lets you catch bugs at compile time thanks to static typing, but the TypeScript compiler has no idea what shape the JSON coming back from an external API takes unless a developer defines it by hand. Every time an API spec and a sample response drift apart, or a field gets added or removed, the type definitions have to be updated manually — and this gap between "what the types say" and "what the API actually returns" has been a recurring headache on many frontend projects.

A JSON-to-TypeScript converter tackles this by working backward from an actual sample JSON response to infer the types mechanically, which speeds up the process considerably. A well-known tool in the same space is quicktype, an open-source project that can generate type definitions for multiple languages and is known for supporting a wide range of input formats, including JSON Schema and GraphQL schemas.

The difficulty with type inference is that JSON itself carries no information about whether a field is always present or might become null in the future. Because of this, auto-generated type definitions are never a complete solution — the standard practice is to treat them as a first draft that reflects only the structure of this particular sample, and to cross-check and adjust them against the real API specification.