JSON to TypeScript Converter

How to convert JSON to TS

1. Paste a real payload. Copy a response from the browser's Network tab, Postman or curl. JavaScript object literals also work (unquoted keys, single quotes, trailing commas), because the input is repaired before inference.
2. Name the root. Set Root name to the domain concept, such as User or OrderResponse. Nested types are named from their keys, so the whole set reads well.
3. Pick the output. Choose interface or type for plain type checking, class if your code creates instances, and Zod if you also want to validate data at runtime.
4. Review and copy. Check every ? and | null against your API docs, then copy the result or download it as a .ts file.

How the types are inferred

JSON carries no schema, so the converter works it out from the values it sees. These are the rules:

Example: optional detection across array items

[
  { "sku": "A-1", "color": "red", "surcharge": 0 },
  { "sku": "A-2", "color": "blue" }
]

// generated
export interface Root {
  sku: string;
  color: string;
  surcharge?: number;   // present in item 0, missing in item 1
}

interface vs type vs class vs Zod

An interface disappears at compile time. It does not check the object your fetch call returns. If a wrong type from the server would be a real problem, generate the Zod version and parse data where it enters your app:

import { z } from "zod";
const res = await fetch("/api/user/7");
const user = UserSchema.parse(await res.json());   // throws if the shape is wrong
type User = z.infer<typeof UserSchema>;

JSON to TypeScript POJO and class generator

If you want model classes rather than type-only interfaces — a “POJO” (plain old JavaScript object) model, a DTO for a NestJS controller, or an entity you will decorate for TypeORM — set Output to class. Every object in the sample becomes an exported class, nested objects get their own classes named from their keys, arrays become typed arrays, keys that are not valid identifiers are quoted, and fields missing from some array items are marked optional with ?.

{"id": 1, "tags": ["a"], "owner": {"name": "Ada"}}

// generated with Output: class
export class Root {
  id!: number;
  tags!: string[];
  owner!: Owner;
}

export class Owner {
  name!: string;
}

The ! is TypeScript’s definite-assignment assertion: it tells tsc --strict the field will be filled (for example by Object.assign(new Root(), json) or class-transformer’s plainToInstance) so the class compiles without a constructor. A value that is only ever null in the sample is typed null; widen it by hand (for example to string | null) once you know the real type. Need POJO classes for another language instead? Use the JSON to Java converter.

Getting accurate types from a sample

• Use a representative sample. Include every optional field at least once, and use an array with several items so optional detection has something to compare.
• Check each ? and | null. These are the guesses most likely to be wrong. Compare them with the API documentation or the backend model.
• Narrow primitives by hand. "status": "active" becomes string. If the API only returns a few values, change it to "active" | "archived". Dates arrive as string, and big IDs are best typed as string too, because JavaScript numbers lose precision past 2⁵³.
• Regenerate after API changes instead of maintaining the output by hand. To see what changed between two payloads, compare them in the JSON diff checker first.

Other ways to generate types

# quicktype: several samples, many languages, JSON Schema input
npx quicktype -l ts -s json -o types.ts sample1.json sample2.json

# from an OpenAPI spec instead of a sample
npx openapi-typescript openapi.yaml -o api-types.ts

If your API has an OpenAPI or JSON Schema definition, generating types from that is more reliable than inferring them from a sample. Use this converter when all you have is real data.

Frequently asked questions