How to Convert JSON to TypeScript Interfaces

When an API gives you JSON, TypeScript wants a shape. You can write interfaces by hand, but that is slow and easy to get wrong when the sample is nested or contains arrays, nulls, and optional fields. This guide shows how to convert JSON to TypeScript cleanly, with practical rules for interfaces, type aliases, optional keys, and nested data.

The quickest way: generate TypeScript from JSON online

Paste a JSON sample into the JSON to TypeScript converter, choose whether you want interfaces or type aliases, set the root name, and generate the result. The tool infers nested types, detects optional fields from array samples, and runs entirely in your browser.

Because API responses can include private or production data, prefer a client-side JSON to TypeScript tool. Your JSON should not need to leave your machine just to generate a type.

Use it when: you want usable TypeScript types fast, without installing a code generator.

Interfaces vs type aliases

Both are valid TypeScript, but they fit slightly different styles.

Use an interface when you are describing object shapes that may be extended:

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

Use a type alias when you want unions, primitives, tuples, or a style that keeps every generated shape as type:

type User = {
  id: number;
  name: string;
};

For API models, either is fine. Pick the style your codebase already uses and stay consistent.

Arrays reveal optional fields

A single JSON object cannot prove a field is optional. An array of objects can:

[
  { "id": 1, "name": "Ada", "role": "admin" },
  { "id": 2, "name": "Alan" }
]

The generated type should mark role as optional:

interface User {
  id: number;
  name: string;
  role?: string;
}

This is one of the biggest advantages of generating TypeScript from a representative sample instead of a tiny one-row example.

Null is not the same as optional

These two fields mean different things:

{ "middleName": null }

{ "name": "Ada" }

middleName: string | null means the key exists and can hold null. middleName?: string means the key may be missing. Some teams prefer treating null as optional; others want a strict | null union. A good converter lets you control that behavior.

Nested objects need useful names

Inline nested types become hard to read quickly:

interface User {
  address: {
    city: string;
    zip: string;
  };
}

For larger structures, named nested interfaces are cleaner:

interface User {
  address: UserAddress;
}

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

Name the root type carefully - User, Order, ApiResponse, or SearchResult is much better than Root.

Watch for mixed arrays

JSON allows arrays with mixed values:

[1, "two", null]

TypeScript should represent that as a union:

type Value = Array<number | string | null>;

For object arrays, mixed shapes can produce optional fields or unions. If the generated type looks too loose, improve the JSON sample so it represents the real API contract.

Convert JSON to TypeScript in code

For a production SDK, you usually want types from the source of truth: OpenAPI, JSON Schema, or a checked API contract. But for day-to-day work, a generated type from a sample is perfect for:

• typing a new fetch response
• building a mock object
• documenting a webhook payload
• turning a one-off export into a typed utility

After generation, paste the type into your codebase and tighten names, comments, or literal unions by hand if needed.

Which method should you use?

For quick API typing, use the online JSON to TypeScript converter: paste a realistic sample, choose interface or type alias, and generate. For long-lived public APIs, generate from OpenAPI or JSON Schema where possible. Either way, watch optional fields, nulls, and nested names - those are the details that make the generated type useful.

Need a machine-readable contract too? Try the JSON Schema Generator. Working with raw data first? Use the JSON Viewer or JSON Formatter.