What JSON to TypeScript does
Typing an API response by hand is tedious and easy to get subtly wrong. Paste a real JSON payload here and you get TypeScript interfaces with each field's type inferred from the value it holds, nested objects promoted into their own named interfaces, and array element types worked out from the items present. Identical shapes are emitted once rather than repeated, so a response containing twenty rows of the same object produces one interface rather than twenty. Because everything runs in your browser, you can paste a genuine production response — including one with customer data in it — without that payload leaving your machine.
Where this helps
Typing a third-party API
When an API has no published types, a real response is the fastest way to a working interface you can refine as you learn the edge cases.
Building mock data for tests
Generated interfaces give test fixtures a shape the compiler can check, so a mock that drifts from the real response fails at build time.
Migrating JavaScript to TypeScript
Capture the payloads a legacy module already handles and turn them into interfaces, rather than reading the code to guess what the data looks like.
Documenting an undocumented endpoint
An interface is a compact, precise description of a response shape — often clearer to a colleague than a prose description of the same thing.
Using JSON to TypeScript
- 1
Paste a representative JSON response into the input box.
- 2
Set the root interface name to something meaningful, such as the endpoint the payload came from.
- 3
Choose whether fields that are null in this sample should be marked optional.
- 4
Copy the generated interfaces, then review them against your API's real schema before relying on them.
What a single sample can and cannot tell you
Type inference from one payload is genuinely useful but structurally limited, and being clear about the limits is what stops the output causing bugs. The generator sees the values present in the sample you paste and nothing else, so a field that is a string here but sometimes null in production is typed as string, and a field that this particular response omits entirely does not appear at all. Neither is a flaw in the inference — it is the boundary of what one example can prove. Treat the result as a well-informed first draft: mark genuinely optional fields with ?, widen fields that can hold more than one type to a union, and replace loose types such as string with a literal union where the API only ever returns a fixed set of values. If you can obtain several representative responses, generating from each and comparing the differences is the quickest way to discover which fields actually vary.
How nested objects and arrays are named and deduplicated
Every nested object becomes its own exported interface rather than being inlined, because a named type is far easier to reference elsewhere in your code than a deeply nested anonymous shape. Names are derived from the key that held the object, converted to upper camel case, with a numeric suffix if that name is already taken. Arrays are inspected element by element: if every element shares a type the result is T[], and if they differ the result is a union of the types present, written as (A | B)[]. An empty array is the one case with no information to work from, so it becomes unknown[] and needs your input. Structurally identical objects are emitted once and reused, which keeps the output readable — a paginated response with fifty items yields one item interface rather than fifty near-identical ones.
Tips
- Paste the largest, most complete response you can find — an example with every optional field populated produces a far more useful interface.
- Rename the generated root from Root to the resource it represents, so the type reads naturally at every call site.
- For an API you do not control, consider validating responses at runtime with a schema library as well; a TypeScript interface is erased at compile time and cannot catch a server that changes its output.