JSON to TypeScript Interface Generator

What this generator infers

The page reads a concrete JSON value and describes its visible shape using TypeScript. Strings become string, finite numbers become number, booleans become boolean, and JSON null becomes null. Objects receive named interfaces, while arrays receive element types. A root primitive or root array is represented by a type alias because an interface can only describe an object-like shape.

Nested interface names are derived from property paths. A user object becomes User; an array stored under orderItems becomes OrderItem. Names are converted to PascalCase and cleaned so the generated identifier begins with a valid TypeScript character. Property names that are not ordinary identifiers are quoted.

Arrays, mixed values, and unions

An empty array does not reveal its future element type, so the generator uses unknown[] instead of claiming a string, number, or object. A mixed primitive array can create a union such as (number | string)[]. Parentheses make the intended array element union clear.

For arrays of objects, the generator examines every sample object rather than only the first. Properties missing from some objects become optional. Values observed with different types become unions. This is more informative than copying the first row, but it still reflects only the examples supplied. A later API response may introduce another variant.

Optional and readonly settings

Enable “Make all fields optional” when the target object is a partial update, configuration override, or incomplete draft. This adds a question mark to every property. Optionality discovered from inconsistent array objects is applied even when the global option is off.

Readonly properties prevent ordinary assignment through that TypeScript type; they do not freeze the runtime JavaScript object. The export option adds export before interfaces and aliases so the declarations can be imported from another module. These settings affect generated syntax, not the input JSON.

Using generated types responsibly

1. Start with a representative sample containing normal, empty, null, and edge-case values where possible.
2. Generate the interfaces, then compare them with the official API schema or backend model.
3. Rename generic nested interfaces when domain-specific names would be clearer.
4. Decide whether nullable and optional mean different things in the API. A missing field and a field containing null are not identical.
5. Add literal unions, branded identifiers, date handling, generics, comments, and validation rules manually where needed.
6. Use runtime validation for untrusted data; TypeScript types disappear when JavaScript runs.

Reviewing generated names and future changes

Path-derived interface names are intentionally descriptive, but deeply nested payloads can produce long names. Rename them to stable domain terms such as Customer, InvoiceLine, or PaginationMeta before committing the file. Keep those names independent from one temporary endpoint path when several responses share the same concept. Regenerate or compare types whenever an API version changes, and review the diff instead of replacing a carefully maintained model blindly. Generated declarations are a starting point: comments, imported shared types, deprecated fields, discriminated unions, and business invariants still require human knowledge.

Common inference traps

• Dates: JSON dates are strings. The generator cannot know whether a string should become Date, remain ISO text, or use a domain-specific type.
• Integers: TypeScript uses number for ordinary JSON numbers and does not create an integer type.
• Large identifiers: JSON numbers beyond JavaScript’s safe integer range may already have lost precision. APIs should often send them as strings.
• Null-only fields: a sample containing only null provides no evidence for the non-null type.
• Empty objects: an empty object reveals no properties and may require a manually defined record or interface.