JSON → TypeScript Interface Generator

Paste a raw JSON object or API response, and get back a matching TypeScript interface definition — with correct types, optional field detection, and nested interfaces for embedded objects — generated instantly and locally.

Why hand-writing types from a JSON response is a bad use of your time

Manually writing a TypeScript interface to match a real API response is tedious and genuinely error-prone in a specific way: it’s easy to miss that a field is sometimes null, guess wrong on whether a number should be typed as a plain number or a more specific union, or forget to properly type a deeply nested object several levels down. This tool does the mechanical part — inferring the correct type for every field including nested objects and arrays — so you can focus your actual attention on refining the types that need human judgment, like whether a string field is really a fixed set of literal values that should be a union type instead.

How to use it

1. Paste a JSON object — a sample API response, a config object, anything with real or representative field values — into the input panel.
2. Get back a complete TypeScript interface instantly, with every field’s type inferred from its actual value, including nested objects generated as their own separate named interfaces rather than inline anonymous types, keeping the output readable.
3. Set your root interface name, and nested interfaces are automatically named based on their parent field (so a user.address object becomes an Address interface referenced from the User interface).
4. Toggle whether array fields with a single sample item should be typed based on that item’s shape (Item[]) — the standard and usually correct assumption for JSON arrays where every item follows the same structure.
5. Choose between generating a TypeScript interface or a type alias, matching whichever convention your codebase already follows.
6. Toggle whether to mark all fields as optional (field?: type) by default, useful when working from a single example that might not represent every field always being present in every real response.

Common situations this solves

• Typing a new API integration quickly, generating a starting-point interface from a real sample response rather than writing every field definition by hand.
• Catching a type mismatch bug, by regenerating an interface from a fresh real response and diffing it against your existing hand-maintained type to spot a field that changed shape or a new field the API started returning.
• Documenting an external API’s response shape for a team, producing a readable TypeScript representation from a raw response even if you’re not using the interface directly in code.
• Speeding up prototyping, getting rough-but-usable types in place immediately so you can start writing type-safe code against a new data source without a manual typing detour first.
• Understanding a complex, deeply nested JSON structure, since the generated interface’s clear field-by-field breakdown is often easier to scan than the raw JSON itself, especially for spotting the overall shape at a glance.

Frequently asked questions

Does the generated interface account for fields that might be null or missing in other responses, not just the one I pasted?

Only to the extent the sample itself reveals — if a field is null in your pasted example, the generated type will correctly include null in the type union. But if a field simply doesn’t appear in this particular response despite sometimes existing in others, the generator has no way to know that from a single sample; use the “mark all fields optional” toggle as a safety net when you’re not fully confident one example represents every real-world response shape.

How does it decide the type for an array — does it check every item or just the first one?

By default it uses the first item as the representative shape for the array’s type, on the assumption that all items in a JSON array typically share a consistent structure, which holds true for the vast majority of real-world API responses. If your array genuinely contains items of meaningfully different shapes, you’ll want to manually adjust the generated union type afterward, since automatically inferring a correct union from mixed array contents is a more ambiguous problem.

Can this detect that a string field should actually be a more specific literal type, like "pending" | "active" | "closed"?

Not automatically from a single sample, since a union of literal values can only be inferred from seeing multiple different real examples of that field. If you know a field is a fixed enum-like set of string values, that’s a manual refinement worth making to the generated type afterward, since it gives you much better type safety than a plain string.

Does the generator produce valid, ready-to-use TypeScript, or just an approximation I need to heavily edit?

The output is valid, directly usable TypeScript as-is for straightforward JSON — the main manual refinement most people do afterward is exactly the kind of domain-knowledge adjustments mentioned above (literal unions, marking fields optional based on real API knowledge) rather than fixing broken syntax.

What happens with a JSON field whose value is an empty array or empty object?

An empty array has no items to infer a type from, so it’s typed as unknown[] or any[] (configurable) by default, flagged for you to manually specify once you know what the array is meant to contain. An empty object similarly generates an empty interface as a placeholder, since there’s genuinely no information in the sample to infer field names or types from.