How are nested objects named?

Nested interfaces get named by combining the parent interface name with the property name, converted to PascalCase. A 'user' object nested inside 'Root' becomes RootUser, and 'user.address' becomes RootUserAddress. PascalCasing strips anything that isn't a letter or digit and capitalizes the start of each remaining word, so a key like 'user_id' or 'user-id' still produces a clean UserId segment in the generated name. A key that starts with a digit gets an underscore prefix, since TypeScript identifiers can't begin with a number. This means every nested interface name is fully determined by its path in the JSON, which keeps names predictable and stable across regenerations. But it also means two structurally different objects living at the same property name in different branches (say, two separate 'address' fields with different shapes) will collide, and only the first one encountered gets kept. If that happens, rename the root type or restructure your sample so the colliding branches produce different paths.

What happens when an array contains objects with different keys?

The generator merges the shapes across every item in the array. It collects the union of all keys seen anywhere in the array, and any key that isn't present in every single item becomes optional, marked with a trailing ? on the generated interface. An array where only the second of two user objects has an 'admin' key, for example, produces admin?: boolean rather than admin: boolean. This merging happens per array, using only the items actually present in your pasted sample, so the accuracy of the optional/required split depends entirely on how representative that sample is. A field that's actually sometimes missing in production but present in every item of your sample will incorrectly come out as required. For best results, include at least one array item that omits any field you know can be absent.

Does it detect union types for mixed-type arrays?

Yes. When an array mixes primitive types (numbers and strings in the same array, say), the generator collects the distinct types seen, in the order they first appear, and produces a parenthesized union array type like (number | string)[] instead of picking one type or falling back to unknown[]. If every element ends up the same type, it collapses to the plain array form, string[] rather than (string)[]. This only applies to primitives in a flat array. If the array instead mixes primitives and objects, or contains nested arrays with differing element types, the union still forms correctly at that level, since the type inference applies recursively per array rather than assuming a single homogeneous shape.

Can I rename the root interface?

Yes. There's a root type name field above the input panel (defaults to "Root") that sets the base name every generated interface derives from, so renaming it to, say, "ApiResponse" changes RootUser to ApiResponseUser throughout the output. Do this before copying the result into a real project — "Root" rarely reads well as a type name once it's actually used elsewhere in your code. One caveat: if your JSON's top-level value is itself an array of objects rather than a single object, changing the root name doesn't avoid the naming collision described in the next question, it just changes which name collides.

Is my JSON data uploaded to a server?

No. The generator runs entirely in your browser using JSON.parse() followed by a pure JavaScript walk over the resulting structure. There's no backend endpoint this page calls to produce the interfaces, and nothing about your input or the generated output gets sent over the network, logged, or stored. That matters because API responses you're typing are often real production data, sometimes including internal field names, user data shapes, or infrastructure details you wouldn't want leaving your machine just to generate a type. Open your browser's network panel while generating if you want to confirm it yourself — there's no outgoing request tied to the JSON you pasted.

How is this different from the JSON Schema Generator?

This tool produces TypeScript interface declarations, source code meant to be pasted into a .ts file for compile-time type checking. It disappears entirely once your code is compiled and provides zero runtime protection. The JSON Schema Generator instead produces a JSON Schema document, a data structure that a validator library like Ajv can check incoming data against at runtime, catching a malformed API response even in production where TypeScript's compile-time types no longer exist to help. Many projects use both: TypeScript interfaces (from this tool) for editor autocomplete and catching mistakes while writing code, a JSON Schema (from the other tool) for actually rejecting bad data once the code is running. If you only need one, pick based on when you need protection — while coding, use this tool; against a live untrusted request, use the schema generator.

What happens when the top-level JSON value is an array of objects?

The generator names the array's item interface directly after the root type name, then also emits a type alias with that same root name pointing at an array of it — interface Root { ... } followed by type Root = Root[]. Both declarations share the identifier "Root", which TypeScript rejects outright as a duplicate identifier, so the output as generated won't compile. Renaming the root type name field doesn't fix this, since whatever name you choose gets used for both declarations. The fix is to manually rename one of the two, typically the interface to something like RootItem, after copying the output into your project. This is a known limitation of the naming scheme, not a bug that gets fixed by different input. It only affects top-level arrays of objects, since nested arrays already get a distinct child-derived name.

How are null values and optional fields typed differently?

A key whose sample value is null gets typed as the literal type null, not string | null or anything broader, and it isn't marked optional — the key still exists in the interface without a ?. A key marked optional (with ?) is a separate signal entirely: it means the key was absent from at least one item in a merged array, and it says nothing about whether the value can be null when present. These are easy to conflate but represent different real-world situations. null means "this field exists and was explicitly set to null in your sample." Optional means "this field is sometimes missing altogether." If your API can return a field as either present-with-a-value or entirely absent, and you only have a sample where it's null, the generated type won't capture the "absent" case. Widen it by hand to a union like string | null, or mark the field optional yourself if you know both situations occur.

JSON to TypeScript Converter - Generate Interfaces Online

Overview

Introduction

Hand-writing TypeScript interfaces for a large API response is tedious and error-prone. This tool infers interfaces directly from a real JSON sample, so the types you get actually match the data your code will receive.

It exists because keeping types in sync with an API by hand doesn't scale. A response with a dozen nested objects and optional fields takes real effort to model correctly, and it's easy to miss an optional property that just happens to be present in the one example you looked at. Generating from an actual payload removes that guesswork — the output is derived mechanically from the data rather than typed from memory.

What Is JSON to TypeScript Converter?

A JSON-to-TypeScript generator walks a JSON sample and produces one or more `interface` declarations that describe its shape: property names, primitive types, nested object types, and array element types.

Unlike a schema format, the output is TypeScript source you paste directly into a `.ts` file. There's no intermediate representation to consume at runtime, the generated interfaces exist purely for compile-time checking, which is exactly what you want when the only goal is catching a typo'd property name or a wrong assumption about a field's type before it ships.

How JSON to TypeScript Converter Works

For each object encountered, the generator creates a named interface using PascalCase derived from the property path. Arrays of objects have their element shapes merged, so any key missing from at least one array item becomes optional. Arrays of primitives become typed arrays, and arrays mixing primitive types become union arrays. Nested objects recursively generate their own named interfaces instead of being inlined, which keeps the output readable.

Because inference works from shape-merging rather than a fixed schema, an array with three items that each expose slightly different keys still produces a single, correct interface. The generator takes the union of all keys seen and marks anything not present in every item as optional with a `?`. It's the same reasoning a developer would apply manually, just applied consistently, without missing an item three levels deep in a large payload.

When To Use JSON to TypeScript Converter

Use it right after receiving a new API response you need to consume in a TypeScript project, when writing a mock or fixture that needs a matching type, or when documenting the shape of a JSON payload for teammates.

It's also a starting point rather than a final answer. Generate the interface from a representative sample, then rename the auto-derived PascalCase names and tighten any fields that deserve a string literal union instead of a bare `string`. That's still faster than starting from a blank file, even with some manual cleanup left over.

Often used alongside JSON Schema Generator and JSON Formatter & Beautifier.

Features

Advantages

Saves significant time versus hand-writing interfaces for nested API responses.
Infers optional properties automatically from inconsistent sample data.
Produces named, reusable nested interfaces instead of a single deeply-inlined type.
Detects primitive union types in mixed arrays.

Limitations

Inference is based only on the sample you provide, so fields absent from your sample won't appear in the generated type.
Cannot infer string literal unions, enums, or branded types; string fields are always typed as `string`.
Does not generate JSDoc comments or validate the generated code against your project's lint rules.

TypeScript Interfaces vs. JSON Schema

TypeScript Interfaces vs. JSON Schema
	TypeScript interfaces (this tool)	JSON Schema
Gives compile-time autocomplete and type checks	Yes	No, needs a separate type-generation step
Validates data at runtime	No, types disappear at compile time	Yes, with a validator like Ajv
Consumed by OpenAPI and API gateways	No, needs a conversion step	Yes
Best for	Type-safe TypeScript code	Validating incoming API payloads

Examples

Object with a nested array and a nested object

Input

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

Output

interface Root {
  id: number;
  tags: string[];
  author: RootAuthor;
}

interface RootAuthor {
  name: string;
}

The top-level interface is declared first, with the nested "author" object referenced by its derived name RootAuthor. The RootAuthor interface itself is declared afterward. Nested objects always become their own named interface rather than being inlined.

Array of objects with inconsistent keys

Input

{"users":[{"id":1,"name":"Ada"},{"id":2,"name":"Bo","admin":true}]}

Output

interface Root {
  users: RootUsers[];
}

interface RootUsers {
  id: number;
  name: string;
  admin?: boolean;
}

"admin" appears in only the second array item, so the merged interface marks it optional with a ? instead of dropping it or requiring it on every item.

A null field

Input

{"id":1,"middleName":null}

Output

interface Root {
  id: number;
  middleName: null;
}

A null sample value is typed as the literal null, not string | null or unknown. The key is still required (no ?), since null is a value, not an absence.

Mixed-type array becomes a union

Input

{"values":[1,"two",3]}

Output

interface Root {
  values: (number | string)[];
}

When array elements aren't all the same primitive type, the generator produces a parenthesized union array type listing each distinct type once, in first-seen order.

Keys that aren't valid identifiers

Input

{"user-id":1,"2fa":true}

Output

interface Root {
  "user-id": number;
  "2fa": boolean;
}

Keys containing a hyphen or starting with a digit aren't valid bare TypeScript identifiers, so the generator emits them as quoted string-literal property names instead, which is still valid interface syntax.

Top-level array of objects (naming collision)

Input

[{"id":1,"name":"Ada"},{"id":2,"name":"Bo"}]

Output

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

type Root = Root[];

When the whole JSON document is an array of objects, the item interface is named directly after the root name, and a type Root = Root[] alias gets added for the array itself. Both declarations share the name "Root", which TypeScript rejects as a duplicate identifier, so you'll need to rename one of the two by hand before using this output. Renaming the root name field first doesn't avoid the collision, since both declarations always inherit whatever name you choose.

Invalid JSON input

Invalid input

{"a": 1,}

Parser error

SyntaxError: Expected double-quoted property name in JSON at position 8 (line 1 column 9)

The generator parses your input with JSON.parse() before doing any type inference, so a trailing comma or any other syntax error gets reported immediately as a parse error, in the exact same wording you'd get from the JSON Validator, rather than the generator attempting a partial or best-guess type.

Corrected version

{"a": 1}

Best Practices & Notes

Best Practices

Use a JSON sample that includes optional/nullable fields in at least one representative case so the generator can infer them correctly.
Rename generated interfaces to something more meaningful than the auto-derived PascalCase names before committing them.
Re-run generation whenever the upstream API shape changes rather than hand-patching stale types.
When the top-level JSON value is an array of objects, rename either the generated interface or the type alias by hand before compiling, since the tool always emits both under the same identifier.
Prefer a sample array with two or three items that differ slightly in shape over a single item, since a one-item array can't reveal which fields are ever actually optional.
Run the generated output through your project's own tsc or linter before committing it. The generator doesn't check the result against your existing type names or style rules.

Developer Notes

Interface names get deduplicated by name. If two different branches of the JSON produce the same derived interface name, the second declaration is treated as identical for output purposes, and only the first one generated is kept, even if the underlying shapes actually differ. For genuinely different shapes that happen to collide, rename the root type before generating so the derived names diverge. Property names are validated against the same bare-identifier grammar TypeScript itself requires for unquoted object keys. Anything that fails that check, a hyphenated key, a key starting with a digit, gets emitted as a quoted string-literal property instead of a bare identifier, which keeps the output valid without needing to rename the source data. One edge case worth knowing about ahead of time: when the top-level JSON value is itself an array of objects, the generator names the item interface directly after the root name and also emits a type Root = Root[] alias, so both declarations end up sharing the same identifier. TypeScript rejects that as a duplicate identifier, and changing the root name field doesn't avoid it, since both declarations always inherit whatever name is chosen. The output needs a manual rename of one of the two before it'll compile.

JSON to TypeScript Converter Use Cases

Typing a new REST or GraphQL API response in a TypeScript client
Generating a starting type for a JSON fixture in tests
Documenting a webhook payload shape for other engineers
Bootstrapping types for a JSON config file
Generating a quick reference type while reviewing a pull request that changes an API response shape
Producing types for a JSON payload from an internal tool or admin API that has no OpenAPI spec of its own

Common Mistakes

Generating types from a single sample and assuming every field is always present. Use multiple representative samples when possible.
Not renaming the generic derived interface names before shipping the code.
Expecting numeric string fields (like "42") to be typed as `number`. They remain `string` since that's their actual JSON type.
Feeding the generator a top-level array without expecting the interface/type-alias naming collision. The generated code needs a manual rename before it'll compile.
Assuming a field typed as `null` in the output means "optional". The generator only marks a key optional when it's missing from at least one array item, not when its present value happens to be null.

Tips

If your API has optional fields, include a JSON sample where at least one object omits that field so it's correctly marked optional.
Combine with the JSON Schema Generator when you need runtime validation in addition to compile-time types.
If the top-level JSON value is an array, rename either the interface or the type alias in the generated output before pasting it into your project, since both declarations share a name and TypeScript will otherwise reject them as duplicates.
Paste a representative sample that includes any hyphenated or numeric-looking keys your API actually uses, so you can see upfront which property names will need quoted syntax in the interface.

JSON to TypeScript Converter

Overview

Introduction

What Is JSON to TypeScript Converter?

How JSON to TypeScript Converter Works

When To Use JSON to TypeScript Converter

Features

Advantages

Limitations

TypeScript Interfaces vs. JSON Schema

Examples

Object with a nested array and a nested object

Array of objects with inconsistent keys

A null field

Mixed-type array becomes a union

Keys that aren't valid identifiers

Top-level array of objects (naming collision)

Invalid JSON input

Best Practices & Notes

Best Practices

Developer Notes

JSON to TypeScript Converter Use Cases

Common Mistakes

Tips

References

Frequently Asked Questions