JSON to TypeScript

Q: How does it know which fields are optional?

By comparing every element of an array rather than typing from the first one. If your sample contains a list of objects and a key appears in some of them but not others, that key is marked optional with a question mark. This is the single most valuable thing a sample-based generator can do, and it only works if you give it enough data — paste one object and every field looks required, because from that one object every field is. Paste the whole array from a real API response and the optionality falls out of it.

Q: What happens when a field has different types in different records?

It becomes a union rather than collapsing to any. A field that holds a number in one record and a string in another is typed as number | string, which is both accurate and something you probably want to know about — inconsistent types in an API response are usually a bug on one side or the other. Null is handled the same way, so a field that is sometimes null becomes string | null, which is exactly the type that forces you to handle the null case.

Q: Why do two nested objects sometimes share one interface?

Because they have the same shape, and emitting the same structure twice under two names is noise rather than information. If an API returns an author object and an editor object with identical fields, the generator produces one interface and references it from both places. When the shapes genuinely differ, even by one optional field, they stay separate. This keeps the output proportional to the number of distinct shapes rather than the number of places they appear.

Q: What does it do with an empty array?

It emits unknown[] and tells you why. An empty array carries no information about what it would contain, so any element type would be a guess — and unknown is the honest answer that forces you to look. This is worth checking whenever you see it in the output, because it usually means your sample did not include a populated example of that field and the real type is knowable if you fetch more data.

Q: Should I use an interface or a type alias?

For plain data shapes like these the two are nearly interchangeable, and both options are offered. Interfaces can be reopened and extended by later declarations, which is useful when you are describing something a third party might augment. Type aliases cannot be reopened, which some teams prefer precisely because it makes the shape final. The practical advice is to match whatever the codebase already uses rather than mixing both.

Q: Is generated code enough, or should I validate at runtime?

These types describe what your sample looked like, not a guarantee about what the server will send tomorrow. TypeScript checks are erased at compile time, so nothing stops an API from returning a different shape at runtime and your typed code from believing it. For an internal API where you control both ends the generated types are usually enough. For a third-party API, treat these as a starting point and add a runtime validator so a change in the response surfaces as a clear error rather than an undefined somewhere deep in your code.

Turn a JSON sample into TypeScript interfaces, with optional fields detected across array elements and union types instead of any.

JSON sample

Root interface name

Use interface Readonly fields Nullable as optional

TypeScript

Generation happens entirely in your browser, so a real API response containing real data never leaves your machine.

What It Does

Paste a JSON response and get the TypeScript interfaces that describe it. The value is in what the generator works out rather than in the transcription itself. It reads every element of an array instead of typing from the first, so a key that appears in some records and not others comes back marked optional — which is the difference between types that describe your data and types that describe one lucky sample. Where a field holds different types in different records it emits a union rather than giving up and writing any. And when the same shape appears in several places it emits one interface and references it, so the output stays proportional to the number of distinct shapes rather than the number of times they occur. Everything happens in your browser, which matters when the sample you want to type is a real response containing real data.

When to Use It

An API returns a response you need to consume in a TypeScript project and you want the types without transcribing forty fields by hand.
You are checking whether an endpoint's response is consistent — inconsistent types and unexpectedly optional fields show up immediately in the generated output.
A third-party service changed its response and you want to see the new shape against the types you already have.
You have a large fixture file and want interfaces for your tests without pulling in a code-generation dependency.
You are documenting an internal API and want an accurate description of the payload as it actually is rather than as it was specified.

Worked Examples

[{"id":1,"title":"First","pinned":true},{"id":2,"title":"Second"}]

The optional-field case. Because pinned appears in only one of the two records, it comes back as pinned?: boolean — something a generator reading only the first element would get wrong.

{"page":1,"results":[{"id":9,"author":{"id":1,"name":"Jane"},"editor":{"id":2,"name":"Sam"},"deletedAt":null}]}

Shows two things at once: author and editor have the same shape so they share a single interface, and deletedAt becomes string | null rather than just null, once a populated record is present.

{"id":1,"tags":[],"scores":[1,"high"]}

The honest-uncertainty case. The empty tags array becomes unknown[] with a warning, because nothing in the sample says what it holds, while scores becomes (number | string)[] with the parentheses that keep the meaning correct.

Features

Optional fields detected across every array element

Union types instead of any for inconsistent fields

Identical nested shapes reused as one interface

Array element interfaces named in the singular

Interface or type alias output

Optional readonly modifiers

Nullable fields optionally converted to optional fields

Invalid identifiers quoted automatically

Warnings for empty arrays and array roots

Entirely browser-based with no uploads

How to Use

1. Paste your JSON — ideally a full array of records rather than a single object, so optional fields can be detected. 2. Set a name for the root interface. 3. Adjust the options if you want type aliases, readonly fields or nullable-as-optional. 4. The interfaces appear immediately, along with a summary of what was inferred. 5. Click Copy to take the generated code.

Common Mistakes

Generating from a single object. Every field looks required because in that one object it is — paste the whole array from a real response and the optional fields reveal themselves.
Trusting the types at runtime. TypeScript is erased when it compiles, so nothing stops a third-party API returning a different shape and your code believing the old one.
Accepting unknown[] without checking. It means your sample had an empty array, so the real element type is knowable — you just need a response that includes one.
Ignoring a union you did not expect. A field typed number | string usually means the API is genuinely inconsistent, which is worth fixing rather than typing around.
Pasting production data into a generator you do not control. This one runs entirely in your browser, but that is not true of every tool offering the same feature.

Frequently Asked Questions

How does it know which fields are optional?

What happens when a field has different types in different records?

Why do two nested objects sometimes share one interface?

What does it do with an empty array?

Should I use an interface or a type alias?

Is generated code enough, or should I validate at runtime?