JSON to TypeScript

What JSON to TypeScript does

JSON to TypeScript reads a JSON sample and infers strongly typed TypeScript interfaces that describe its shape. It walks the value recursively: objects become named interfaces, primitive values become the matching string, number, boolean, or null types, and arrays become element types wrapped in brackets. When an array contains different element types, the generator merges them into a union so the result still type-checks against the original data. This is useful when consuming an API that has no published types, when adding type safety to a legacy payload, or when turning a quick fixture into a reusable model.

Arrays of objects are handled with care. Rather than typing only the first element, the tool merges every object in the array into a single interface, collecting the union of keys. Keys that are missing from some elements are marked optional with a trailing question mark, which mirrors how real-world responses include fields only when they are populated. Nested objects are promoted to their own named interfaces derived from the property name, so the output reads like hand-written models instead of one deeply inlined type.

Private browser-based workflow

All parsing and inference happen inside your browser with client-side JavaScript. The tool does not upload your JSON, API responses, identifiers, tokens, or customer-shaped samples to a server, and it does not require an account. That local-only model matters because the data pasted into a type generator is frequently a real production response captured while debugging. Keeping the work on your machine reduces risk and keeps the result instant because there is no network round trip between paste and output.

The interface keeps the JSON input, the root name, and the generated interfaces close together so you can verify the inference before copying it. Results should still be reviewed before being committed: a single sample cannot reveal every optional field, nullable value, or enum the real API can return, so widen the types where your domain knowledge says a field may be absent or take more shapes than the sample shows.

Practical tips

Provide the most complete sample you have, ideally one that includes optional fields populated and an array with more than one element so the merging logic can detect unions and optionality. Rename the root interface to match your domain model before generating. After copying, consider tightening loosely inferred types: replace broad string fields with literal unions for known enums, mark identifiers as branded types if your codebase uses them, and confirm that any field the inferrer typed as null should instead be a nullable union. Browser inference is excellent for a fast first draft, but the final types should reflect the contract your application actually depends on.