JSON to TypeScript — Generate TypeScript Interface from JSON

How the Type Inference Works

The converter runs JSON.parse on your input and then walks the resulting value, deciding a TypeScript type for every property it meets. JSON has six value kinds and TypeScript has a direct equivalent for most of them, so the mapping is largely mechanical.

How Names Are Chosen

Every interface name is the property key with its first letter capitalised, stripped of anything that is not a letter, digit or underscore, and prefixed with I. So address gives IAddress and user-profile gives IUserprofile. Keys are left alone unless they need quoting: first-name and 2fa are emitted as "first-name" and "2fa", which is valid TypeScript and keeps the property name matching the JSON exactly.

One detail surprises people: names are taken from the key verbatim, with no attempt at singularising. A posts array of objects produces interface IPosts and the type IPosts[], so a single post has the plural type name. Rename it to IPost after pasting if that bothers you — it is a two-second edit and the generated code compiles either way.

A Worked Example

The built-in sample has a nested object, an array of strings and an array of objects. Running it with the default root name produces three interfaces, printed innermost first:

interface IAddress {
  street: string;
  city: string;
  state: string;
  zip: string;
}

interface IPosts {
  title: string;
  body: string;
  likes: number;
}

interface IRootObject {
  id: number;
  name: string;
  email: string;
  isActive: boolean;
  age: number;
  address: IAddress;
  hobbies: string[];
  posts: IPosts[];
}

When the top level is an array rather than an object, you also get a type alias. An array of user objects with the root name User yields interface IUser describing one element plus type User = IUser[]; for the collection.

What a Single Sample Cannot Tell You

Generating types from data rather than from a schema has a hard ceiling: the output describes the example you pasted, and nothing more. Knowing exactly where that ceiling sits is what separates a useful starting point from a type that quietly lies to you.

• Optional properties look required. Every key in your sample is emitted as required. If the API omits middleName for most users, the generated interface still demands it. Add ? to any field the API may leave out.
• Nulls collapse to the null type. A field that happened to be null in your sample is typed null, which will reject the string it normally holds. Widen it to string | null — this is the single most common edit needed.
• Only the first array element is read. An array of mixed shapes is described by its first entry alone. If a list contains both free and paid accounts and the first is free, the paid fields never appear.
• Unions are never inferred. A status field of "active" becomes string, not "active" | "archived" | "banned". Narrowing those by hand is usually the highest-value change you can make.
• Dates stay strings. JSON has no date type, so an ISO timestamp is typed string. That is technically correct for the wire format; convert to Date at the boundary rather than pretending the field is already one.

A type is also only a compile-time claim. TypeScript erases interfaces during compilation, so nothing checks at runtime that the response actually matches. Asserting as IUser on a fetch result tells the compiler to stop asking questions; it does not make the data conform. For anything crossing a network boundary, validate the payload with a runtime schema library and derive the type from that schema, so one definition governs both checks.

Where the API publishes a machine-readable description — OpenAPI, JSON Schema, GraphQL — generate from that instead. A schema states which fields are optional, which values are permitted and what each field means, all of which sample data can only hint at. This tool is for the common case where no such description exists and all you have is a response you captured from an endpoint.

Use Cases

Related Tools