JSON to TypeScript

The JSON to TypeScript converter reads a sample JSON value - an API response, a config file, a database record - and writes the TypeScript interfaces that describe it. Nested objects become their own named interfaces, arrays of objects are merged into a single element interface rather than a sprawling union, and keys that are null or missing from some records are marked optional. You paste data you already have; you get types you would otherwise hand-write.

Typing an API response by hand is tedious and error-prone in a specific way: you type what you *think* the endpoint returns, not what it returned. Fields you never noticed get omitted, an integer that is sometimes null gets typed as `number`, and the mistake surfaces at runtime in production rather than in your editor. Generating types straight from a real payload closes that gap, because the shape you compile against is the shape the server sent.

Everything runs in your browser. The inference engine is dependency-free TypeScript, not a wrapper around a remote service, so payloads - which routinely carry access tokens, customer records and internal IDs - never leave the page. Choose interfaces or type aliases, toggle the `export` keyword and `readonly` modifiers, pick your indent width, then copy the output or download a .ts file.

A quick way to see what JSON to TypeScript conversion gives you is the built-in sample. Press Load Sample, then Generate. You get three JSON to TypeScript interfaces: `Root`, `Owner` and `Release`. The second release has no `notes` key, so the merged `Release` interface reads `notes?: string`, and `retiredAt` is null in the only record, so it becomes `retiredAt?: null`. That is the honest result, because one null gives no evidence of the real type. To convert JSON to TypeScript for a real endpoint, paste several records so the inference has more to compare.

The generated interfaces describe the sample you provided, not the API you are calling, and that distinction is the whole risk. A field that happens to be present in every object of your sample is marked required even if the server omits it sometimes, and a field that is null in the sample cannot be distinguished from one that is always null. Empty arrays are the clearest case: an array with no elements gives no information about what it contains. The array merging helps here by combining every object in a list into one interface and marking keys that are missing from some entries as optional, so a larger and more varied sample produces a more honest type. Where the API has a schema or OpenAPI document, generate from that instead and use this for exploring an undocumented response.