Free JSON to TypeScript Interface Generator

What JSON to TypeScript Inference Does and How It Reads a Sample

Consuming an API in TypeScript without types means every property access is a guess the compiler cannot check. Writing the interfaces by hand from a sample response is the obvious fix and the tedious one, particularly when the payload nests four levels deep and half the fields are arrays of objects. This converter reads a JSON sample and infers the full interface set, walking every level and naming nested shapes as it goes. Anyone integrating a third-party API, typing a configuration file, or modelling a MongoDB document reaches for this rather than transcribing 60 fields by hand. The inference is a recursive walk over the parsed value, mapping each JavaScript runtime type to its TypeScript equivalent. A string becomes string, a number becomes number regardless of whether it looked like an integer, a boolean becomes boolean, and null becomes the null type rather than being skipped. An object becomes its own named interface, with the name derived from the property that held it and capitalised, so a field called billing_address produces an interface named BillingAddress referenced from the parent. Arrays are the interesting case. The tool inspects the elements, and if they are all objects it merges their key sets into one interface: a key present in every element stays required, while a key missing from any element is marked optional with a question mark. If elements disagree on a type for the same key, the result is a union like string vertical-bar number. Property names that are not valid TypeScript identifiers — anything with a dash, a space, or a leading digit — are emitted in quotes so the output compiles unchanged. A concrete run. Paste an object with an id of 42, a name of Priya Sharma, an active flag of true, a nullable deleted_at, an address object holding city and pincode, and a two-element orders array where the first item has id and total and the second has id, total, and a coupon string. Set the root name to User. You get four interfaces. User has id as number, name as string, active as boolean, deleted_at as null, address typed Address, and orders typed Order array. Address has city as string and pincode as number. Order has id as number, total as number, and coupon marked optional with a question mark, because only one of the two elements carried it. That optional marker is the part hand-written types almost always get wrong. Where it pays off. A developer wiring up a payment gateway pastes one webhook payload and gets 40 typed fields instead of reading the docs table twice. Someone migrating a JavaScript codebase to TypeScript feeds in a saved fixture from their test suite and has the response shape in seconds. A team documenting an internal service generates the interface, commits it, and treats it as the contract. A developer typing a large config file — a build tool config with nested plugin options — avoids a day of transcription. Someone modelling a Firestore document pastes an export and refines the result rather than starting from an empty file. The important limitation: inference can only describe the sample you provide. Feed it a response where an optional field happens to be absent and that field will not exist in the type at all, which produces a compile error the first time production returns it. Use the richest sample you have, ideally one with every optional field populated and at least two array elements so the merge logic has something to compare. The other thing to fix by hand is over-broad types — a status field that is really one of three values comes out as string, and narrowing it to a literal union of pending, paid, and failed is where the real safety comes from. Also remember null is not the same as optional: deleted_at typed null means it is always null, so widen it to string or null yourself. Everything runs in your browser, so real API responses containing customer data are never uploaded.

🔥 Trending Tools