JSON to TypeScript Generator

Why Generate TypeScript Types from JSON?

Every REST API returns JSON. Every configuration file is JSON. Every database document is JSON. But JSON itself carries no type information — a field called age could be a number, a string, or missing entirely depending on which endpoint you hit and what version of the API you are talking to.

TypeScript solves this by letting you describe the exact shape of the data. Once you have a type, your editor autocompletes every property name, the compiler catches mismatches before your code ever runs, and your teammates immediately understand the structure of any response just by reading the type definition.

The problem is writing those types by hand. A real API response might have 40 fields, several nested objects, and a handful of nullable values. Translating that by hand is tedious, error-prone, and has to be repeated every time the API changes. This tool does the translation for you in milliseconds.

How to Use the JSON to TypeScript Generator

The workflow is straightforward:

1. Get your JSON. Copy it from your browser's Network tab, from Postman, from curl output, or from any JSON file. It can be a single object, a nested object, or an array at the top level.
2. Paste and set the root name. Type a meaningful name for your root interface in the "Root name" field — for example UserProfile or OrderResponse. This makes the generated code immediately readable in context.
3. Choose your output mode. Select "TypeScript Interface" for plain interface definitions, or "Zod Schema" to get runtime-validation schemas that also export the inferred TypeScript type.
4. Click Convert and copy. The generated code appears on the right. Click "Copy" to copy it to the clipboard, then paste it directly into your .ts or .tsx file.

Understanding the Generated TypeScript Interfaces

Take a typical API response:

{
  "id": 42,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "active": true,
  "score": null,
  "tags": ["admin", "editor"],
  "address": {
    "city": "New York",
    "zip": "10001"
  }
}

The generator produces:

interface Root {
  id: number;
  name: string;
  email: string;
  active: boolean;
  score?: string | null;
  tags: string[];
  address: Address;
}

interface Address {
  city: string;
  zip: string;
}

Each JSON type maps to its TypeScript equivalent: strings become string, numbers become number, booleans become boolean. The null value on score becomes an optional field typed as string | null — a safe choice that handles both a real value when it eventually arrives and its absent state. The array of strings becomes string[]. The nested address object generates its own Address interface, which is referenced by name from the parent.

Working with Nested Objects and Arrays

Nested objects are one of the most common pain points when writing types by hand. Consider an e-commerce order response:

{
  "orderId": "ORD-9981",
  "total": 149.99,
  "customer": {
    "name": "Bob Smith",
    "loyalty": { "tier": "gold", "points": 4200 }
  },
  "items": [
    { "sku": "SHOE-42", "qty": 1, "price": 89.99 }
  ]
}

The generator handles this by creating one interface for each distinct object shape it encounters, naming each after the key it was found under:

interface Order {
  orderId: string;
  total: number;
  customer: Customer;
  items: ItemsItem[];
}

interface Customer {
  name: string;
  loyalty: Loyalty;
}

interface Loyalty {
  tier: string;
  points: number;
}

interface ItemsItem {
  sku: string;
  qty: number;
  price: number;
}

After generating, rename ItemsItem to OrderLineItem to give it a domain-meaningful name. The initial generation gives you a correct starting point — you refine the names to fit your codebase conventions.

For arrays at the root level — common when an API returns a list of records — the tool produces a type alias rather than an interface:

// Input: [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
type Users = UsersItem[];

interface UsersItem {
  id: number;
  name: string;
}

TypeScript Interface vs. Type Alias: When to Use Each

TypeScript offers two ways to describe object shapes: interface and type. For the JSON-to-TypeScript use case the practical differences are minor, but knowing them helps you decide which to use after generation.

Interfaces support declaration merging — you can write two interface Foo blocks in the same scope and TypeScript combines them. This is useful when a library defines an interface and you need to extend it. Interfaces also produce clearer error messages in many editors because TypeScript can name them by their declared name.

Type aliases are more flexible: they can express union types (type Status = 'active' | 'inactive'), intersection types, mapped types, and conditional types — none of which interfaces support. For plain object shapes derived from JSON, both work equally well.

This tool uses interface for object types (matching the most common convention in TypeScript projects) and type for array root types where the shape is expressed as ElementType[].

What Is a Zod Schema and Why Does It Matter?

TypeScript's type system is a compile-time guarantee, not a runtime guarantee. When your application fetches data from an external API, that data arrives as untyped JSON at runtime — TypeScript cannot check it. If the API changes and starts sending a string where you expected a number, TypeScript will not catch it; your code will simply receive the wrong type and fail in unexpected ways.

Zod bridges this gap. A Zod schema is a JavaScript object that describes the expected shape of data and can actively parse and validate incoming data at runtime. When you call UserSchema.parse(apiResponse), Zod checks every field, throws a descriptive ZodError if anything is wrong, and returns the data with the correct TypeScript type attached if everything passes. The z.infer<typeof UserSchema> utility then derives the TypeScript type from the schema automatically, so you never write the type twice.

The generated Zod schema from our earlier example would look like:

import { z } from 'zod';

const RootSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
  active: z.boolean(),
  score: z.string().nullish(),
  tags: z.array(z.string()),
  address: AddressSchema,
});

const AddressSchema = z.object({
  city: z.string(),
  zip: z.string(),
});

type Root = z.infer<typeof RootSchema>;

Zod is particularly valuable at API boundaries, form validation, and environment variable parsing — anywhere external data enters your application.

Common JSON Patterns and Their TypeScript Equivalents

Here are the most frequently encountered JSON patterns and how they translate:

One pattern the tool conservatively handles is mixed-type arrays like [1, "two", true]. These become (number | string | boolean)[]. In practice, REST APIs rarely return mixed arrays — if you see one, it often means the sample JSON is a placeholder and the real structure is more consistent.

After Generation: Improving the Output

The generator gives you a correct and complete starting point. A few refinements make it production-quality:

• Rename interfaces. Auto-generated names like AddressItem or DataItem work but lack domain clarity. Rename them to reflect the business concept: ShippingAddress, ProductVariant.
• Narrow string fields. If a field can only hold specific values — like "active" | "inactive" | "pending" — replace the generated string with the union type for maximum type safety.
• Mark more fields optional. If a sample JSON happens to include a field that is sometimes absent in real responses, add ? to it. Use a representative sample that reflects the full range of responses.
• Use a richer sample. The more complete and representative your input JSON, the better the generated types. If an API has optional fields, find a response where they are populated and one where they are absent, merge them manually, then generate.