JSON to TypeScript

How this tool actually builds the interface tree

This isn't a recursive walk that emits nested interfaces inline — it's breadth-first. Every object found gets queued by name, and a separate generation loop dequeues one at a time, emitting a top-level export interface for each. That's why a deeply nested JSON payload comes out as a flat list of sibling interfaces (Root, User, Address) referencing each other by name, rather than as one interface with types nested inline. It's the same general shape of trade-off C# itself makes: a deeply nested JSON API response, when deserialized into C# via System.Text.Json, also tends to become a flat set of sibling DTO classes referencing each other by type rather than one giant class with anonymous nested types — flat, named, reusable interfaces are easier to work with in both languages than deeply inlined structural types. Names are also deduplicated case-insensitively after PascalCasing — a property called userID and one called userId elsewhere in the payload PascalCase to UserID and UserId respectively, which aren't identical strings but are treated as the same generated interface anyway, since the dedup check ignores case entirely. If those two properties actually have different shapes, only the first one generates the interface and the second silently reuses it.

How to use this tool

1. Paste your JSON payload into the editor on the left.
2. Click Generate.
3. Copy the TypeScript interfaces and paste them into your project.

One real edge case worth knowing

Interface names are deduplicated by name only, not by shape. If two different properties anywhere in your JSON share the same name after PascalCasing — say a top-level address with just a city, and a nested user.address with city and zip — only the first one encountered generates the interface, and the second property gets typed against that same (wrong) shape. We traced this directly: accessing user.address.zip in your TypeScript would fail to compile — "Property 'zip' does not exist" — even though that field is genuinely present in your real JSON data, because the generated interface only reflects the first occurrence's (zip-less) shape. If your JSON reuses a field name for differently-shaped objects, rename one before generating, or expect a mismatch.

What this tool won't get right automatically

JSON has no type system beyond string/number/boolean/null/object/array, so the generated TypeScript is necessarily a narrower view than what your data really represents. An empty array generates unknown[] — there's no element present to infer a type from, so the tool can't guess whether it should be string[] or OrderItem[]; you'll need to fill that in by hand. Every numeric value, integer or decimal, maps to TypeScript's single number type — there's no distinction preserved for values that are really meant to be a string-backed bigint-range ID or a fixed-precision decimal. And a property that's sometimes present and sometimes missing across different API responses won't show up as optional (?) here at all, since the generator only ever sees one JSON sample at a time — it has no way to know a field is optional unless you've pasted an example where it's actually absent.

Arrays have a sharper version of the same problem: only the first element is inspected to infer the item type. A JSON array that mixes shapes — some items with a discount field, some without, because your API only includes it conditionally — generates a type based solely on whichever shape happens to be first in your pasted sample. Paste the same logical array with a different first element and you can get a meaningfully different interface out, even though both are "correct" for that one sample. If your real data has heterogeneous array items, treat the output as a starting union member, not the final type — you'll likely need to turn it into (TypeA | TypeB)[] by hand.