JSON to TypeScript

The JSON to TypeScript Interface Generator converts a JSON object or array into TypeScript interface declarations with correctly typed properties, nested interfaces, and optional field markers. Use it to rapidly type REST API responses, request bodies, and configuration objects in TypeScript, React, Angular, and Node.js projects.

S. Siddiqui

Edited by

S. SiddiquiFounder & Editor-in-Chief
Sources:MDN Web DocsW3CIETFUpdated Jun 2026

What Is the JSON to TypeScript Interface Generator?

The JSON to TypeScript Interface Generator analyses a JSON sample and produces TypeScript interface declarations that describe the shape of the data. Each JSON object becomes a TypeScript interface, each key becomes a typed property, and nested objects produce additional named interfaces. The output is ready to paste into a TypeScript project — giving you compile-time type checking, IDE autocomplete, and self-documenting code immediately, without writing the interface definitions by hand.

TypeScript interfaces are the standard way to describe the structure of JSON data received from a REST API, a configuration file, or a database query result. Without an interface, TypeScript infers the type as any when you use JSON.parse() or an untyped fetch() call, losing all type safety. With an interface, TypeScript validates every property access at compile time, catches typos in field names, and surfaces incorrect assumptions about what properties are optional versus required.

According to the TypeScript Handbook on Object Types, interfaces describe the shape that values must conform to. For JSON-heavy applications — which includes virtually all React, Angular, Next.js, and Node.js backends — defining interfaces for every API response is considered a baseline practice for maintainable TypeScript code. This tool generates those interfaces from a real JSON sample rather than requiring you to transcribe every field manually.

This generator is used by front-end developers integrating REST APIs into React or Angular applications, back-end developers typing Express.js request and response bodies, full-stack engineers working in a monorepo where types are shared between client and server, and developers adopting TypeScript in an existing JavaScript codebase who need to rapidly type their existing API contracts.

How to Use the JSON to TypeScript Interface Generator

  1. Paste your JSON sample. The input should be a representative JSON object or array. If the API returns an array, paste the full array — the generator will create a root interface for the array element type. If some fields are sometimes null or missing, include examples of both to help the generator infer optional types.
  2. Choose a root interface name. Enter a name for the top-level interface in PascalCase — for example User, Product, or ApiResponse. Nested objects are automatically named based on the parent property name. For example, a address property that is an object produces an Address interface.
  3. Review the generated interfaces. Check that each property has the correct type. Strings become string, numbers become number, booleans become boolean, null values produce null or a union type, and arrays produce Type[]. Fields that were null in the sample are marked as Type | null.
  4. Mark optional fields. Properties that are not always present in real API responses should be marked optional with ?: email?: string. If the sample always includes every field, review the API documentation to identify which fields are truly optional and edit the output accordingly.
  5. Copy and paste into your project. Add the generated interfaces to your TypeScript project — typically in a types/ directory or alongside the component or service that consumes the data. Import and use them to type your API responses.

Why Use This Tool

Manually writing TypeScript interfaces from a JSON sample is tedious and error-prone. A typical API response with 20 fields, 3 nested objects, and 2 array properties requires approximately 60 lines of TypeScript interface code. Transcribing that by hand — reading field names, mapping JSON types to TypeScript types, naming nested interfaces — takes 10–20 minutes and introduces transcription errors. This tool does it in under five seconds.

Front-end developers integrating REST APIs

A React or Angular developer receives a new API endpoint from the back-end team. The API documentation includes a sample JSON response. Rather than reading through the sample and typing each interface property, the developer pastes the sample into this generator, copies the output into a types.ts file, and has fully typed response handling before writing a single line of component code. Any mismatch between the interface and the actual response surfaces immediately as a TypeScript compile error.

Back-end developers typing Express or Fastify handlers

A Node.js back-end developer uses TypeScript with Express. Request body types are critical — an untyped req.body is any, meaning field access errors only appear at runtime. Using this generator to produce an interface from a sample request body, then applying it as req.body as CreateUserRequest, brings compile-time validation to the route handler and eliminates a whole category of runtime errors in API endpoint code.

Adopting TypeScript in a JavaScript codebase

A team migrating an existing JavaScript application to TypeScript needs to type all their existing API contracts. Rather than writing interfaces from scratch or from memory, they can run each API endpoint, capture the response, paste it into this generator, and have accurate interfaces for the entire API surface area in a fraction of the time a manual migration would take.

Shared types in monorepos

Full-stack teams in a monorepo share TypeScript types between front-end and back-end. When a back-end engineer adds a new field to an API response, they update the shared type file. This tool gives both teams a quick way to regenerate or verify the shared interface from an actual response sample, ensuring the type definition stays in sync with the real data structure.

Real-World Use Cases

React developer typing a GitHub API response

A front-end developer builds a dashboard that displays repository statistics from the GitHub REST API. The API returns a large nested JSON object for each repository — name, owner object, metrics, topics array, and licence object. Manually typing all of this would take 30 minutes. The developer makes one API call in Postman, copies the response, pastes it into this generator, and has a complete set of TypeScript interfaces in under a minute. The generated Repository, Owner, and Licence interfaces are committed to the project's types directory and used across all repository-related components with full autocomplete.

Angular developer typing a paginated API response

An Angular developer is integrating a paginated product catalogue API. The response wraps the product array in a pagination envelope: {"data": [...], "meta": {"page": 1, "total": 450, "per_page": 20}}. The developer pastes this structure into the generator and receives a ProductListResponse interface with a typed data: Product[] property and a meta: PaginationMeta property. The generator correctly identifies that data is an array of objects and produces a separate Product interface — which the developer then refines to mark optional product fields like description and discount_price accordingly.

Node.js developer typing a Stripe webhook payload

A back-end developer handles Stripe webhook events in a Node.js service. Stripe's event payloads are deeply nested JSON with many optional fields. Rather than relying entirely on Stripe's SDK types (which are comprehensive but sometimes difficult to navigate), the developer pastes a real payment intent webhook payload into this generator and produces a focused interface covering only the fields their handler actually uses. The resulting interface is narrower and easier to reason about than the full SDK type, while still providing complete type safety for the handler's logic.

Team migrating a JavaScript API client to TypeScript

A team of five developers is migrating their JavaScript front-end to TypeScript over three months. They have 35 API endpoints to type. Using this generator, each developer captures real API responses from the staging environment and generates interfaces for their assigned endpoints. Over two weeks, all 35 interfaces are committed to a shared api-types.ts file. TypeScript immediately catches three places where the existing JavaScript code was accessing field names that did not exist in the actual API responses — bugs that had been silently returning undefined in production.

Common Mistakes and Troubleshooting

Using a sample that does not represent optional fields

The generator infers types from the values present in the sample. If a field is always present in your sample but is sometimes null or absent in real API responses, the generator will mark it as required and non-nullable — producing a type that does not match the actual API contract. Always review the generated interfaces against the API documentation and add ? (optional) or | null to fields that are not guaranteed to be present and non-null in every response.

All numeric fields typing as number

TypeScript's number type covers both integers and floats. The generator produces number for all numeric JSON values. If your application logic depends on a field being an integer specifically — such as a page count or an ID — TypeScript's number type is still correct; there is no separate int type in TypeScript. However, if you use runtime validation libraries like Zod, you can add z.number().int() for integer-specific validation on top of the TypeScript type.

Nested interfaces naming conflicts

If two different properties in the JSON have the same key name but different structures — for example, a metadata property in both the root object and inside a nested user object — the generator may produce two interfaces named Metadata. This creates a naming conflict. Review nested interface names in the output and rename conflicting interfaces to be more specific: UserMetadata and RootMetadata, for example.

Arrays of mixed types

JSON arrays that contain elements of different types — such as [1, "hello", null] — produce a union type: (number | string | null)[]. This is correct TypeScript but may indicate a design issue in the API. In practice, most API arrays contain elements of a single type; if you see a union array type in the output, verify that the API truly returns mixed-type arrays rather than an accidental inconsistency in the sample you pasted.

Expecting the generator to handle any values

Fields whose type cannot be inferred — such as a value that is {} (an empty object) or an empty array [] — may be typed as Record<string, unknown> or unknown[] by the generator. These are correct conservative typings. To get more specific types, provide a sample with populated values in those fields so the generator can infer the actual structure.

Last reviewed: June 7, 2026

Frequently Asked Questions

What TypeScript types does the generator produce for different JSON value types?
JSON strings become TypeScript string. JSON numbers become number. JSON booleans become boolean. JSON null becomes null (typically combined as Type | null). JSON objects become a named interface. JSON arrays of objects become InterfaceName[]. JSON arrays of primitives become string[], number[], or a union type (string | number)[] for mixed arrays. Empty arrays become unknown[] and should be manually refined once the element type is known.
What is the difference between a TypeScript interface and a type for JSON data?
Both interface and type can describe the shape of a JSON object in TypeScript. Interfaces are extendable (you can add properties via declaration merging or extends) and are the conventional choice for object shapes. Types are more flexible — they can represent unions, intersections, and primitive aliases. For JSON API response shapes, both work identically. This generator produces interfaces by default, which is the TypeScript community convention for object shapes.
How are optional fields marked in the generated interfaces?
Fields that are null in the sample are typed as Type | null. Fields that are absent from some objects in the sample are marked as optional with ?: (question mark before the colon). To mark a field as optional that is always present in your sample but sometimes missing in real responses, manually add ? to the property in the output: email?: string instead of email: string.
How does the generator handle nested JSON objects?
Each nested JSON object produces a separate named interface. The interface name is derived from the property name converted to PascalCase — an address property produces an Address interface, and userProfile produces a UserProfile interface. The parent interface references the child interface by name: address: Address. All generated interfaces are listed in the output and can be imported together from a single types file.
How do I use the generated interface to type a fetch() response?
Cast the response using the generated interface: const response = await fetch('/api/users'); const data: User[] = await response.json(). More robustly, use a generic fetch wrapper: async function fetchTyped<T>(url: string): Promise<T> { const res = await fetch(url); return res.json() as Promise<T>; } then call fetchTyped<User[]>('/api/users'). For full runtime validation (not just compile-time), use the interface with Zod: const UserSchema = z.object({...}) and parse the response.
Can I generate a Zod schema from the interface?
This tool generates TypeScript interfaces, not Zod schemas. To also get Zod validation, use the ts-to-zod library (npm install ts-to-zod) which takes TypeScript interface definitions and generates corresponding Zod schemas. Alternatively, write your schema in Zod first and infer the TypeScript type from it using z.infer<typeof YourSchema> — this approach is increasingly popular because it gives both runtime validation and compile-time types from a single source of truth.
How do I handle a JSON array at the root level?
If your API returns a root-level array ([{...}, {...}]) rather than an object, paste the array including the brackets. The generator produces an interface for the array element type (e.g. User) and the root type is User[]. Reference this as const users: User[] = await fetchTyped<User[]>('/api/users'). If you want a named type for the array itself: type UserList = User[].
How are JSON keys with hyphens or special characters handled?
JSON keys containing hyphens, spaces, or other characters that are not valid JavaScript identifiers (like created-at or X-Request-ID) are converted to camelCase in the TypeScript interface (createdAt, xRequestId) and the original key name is preserved in a @JsonProperty or similar decorator if needed. If you are using the interface purely for type checking and rely on a JSON parser that maps keys automatically (like class-transformer), the camelCase conversion is correct. If you need exact key names, use bracket notation: data['created-at'].
Can I use the generated interface with axios?
Yes. Axios supports generic typing for responses: const response = await axios.get<User[]>('/api/users'). TypeScript then types response.data as User[]. This provides compile-time checking for all property access on the response data. Axios does not perform runtime validation — it trusts that the response matches the declared type. For runtime safety, combine axios with Zod to validate the response before typing it.
What is the difference between readonly and mutable interface properties?
By default, generated interface properties are mutable — you can reassign them after creation. If you want to prevent mutation (for example, treating API response data as immutable), prefix properties with readonly: readonly id: number. The generator does not add readonly by default, but you can enable it as an option or add it manually to the output. readonly properties cause a TypeScript compile error if code tries to assign to them, which is useful for enforcing that API data is not accidentally mutated.

Rate This Tool

Was this tool helpful?

Be the first to rate this tool

About the Author

S. Siddiqui

S. Siddiqui

Founder & Editor-in-Chief

LinkedIn Profile

S. Siddiqui is the founder and editor-in-chief of YourToolsBase, overseeing all content, tool accuracy, and editorial standards.

View full profile

Related Tools

JSON FormatterJSON MinifierJSON ValidatorJSON to CSV Converter

Authoritative Sources

Formulas and data in this tool are based on guidelines from the above sources.