JSON to TypeScript converter: interfaces from JSON.

JSON has only six kinds of value, and each maps to a TypeScript type. Strings become string, numbers become number, true and false become boolean, null stays null, arrays become T[] and objects become interfaces. TypeScript has no separate integer type, so 42 and 349.5 are both number.

JSON has no date type. Dates arrive as strings such as 2026-10-10T09:30:00Z and are typed as string; convert them to Date objects deliberately when you parse a response. Large integers are another trap: JSON.parse turns every number into a JavaScript double, which is exact only up to 2⁵³ − 1 (9,007,199,254,740,991). 64-bit IDs beyond that are silently rounded, so APIs should send them as strings and your types should say string.

Optional and nullable mean different things. note?: string says the key may be absent; note: string | null says the key is always present but may be null. JSON cannot contain undefined at all, because JSON.stringify drops such keys, so an API that omits empty fields and one that sends null need different types. With the exactOptionalPropertyTypes compiler option, TypeScript also tells a missing key apart from one explicitly set to undefined.

Every object becomes its own named declaration, named after its key in PascalCase, so a customer key produces interface Customer. Items in an array named with a plural are singularised: items gives Item and categories gives Category. If two objects would share a name, the second gets a numeric suffix, such as Item2.

Objects inside an array are merged into one shape. A key that is missing from some items becomes optional (note?: string), and a key whose values differ becomes a union such as number | string. Mixed arrays become union arrays with the parentheses TypeScript needs, such as (string | number)[]. A top-level array produces a type alias, so pasting a list of users gives type Users = UsersItem[] plus the item interface.

Empty arrays become unknown[] and empty objects Record<string, unknown>, because a sample cannot show what they would hold. Keys that are not valid identifiers, such as first-name or 2fa, are quoted. If the JSON is invalid, you get the error with its exact line and column instead of a guess; the JSON formatter can help fix it.

Generated types describe the sample you pasted, not every response the API can send. A field that is a string today may be null tomorrow; a field that happens to be present in every item may still be optional. Paste a response with several varied items to improve the merge, and check optional fields and nullability against the API documentation.

Inference cannot see intent. A status of 'paid' becomes string, not the union 'pending' | 'paid' | 'refunded'; narrow it by hand. A fixed-position array like [51.5, -0.12] becomes number[], not the tuple [number, number]. An object keyed by IDs, such as { 'u_1': {...}, 'u_2': {...} }, produces a fixed interface with those exact keys when you really want Record<string, User>. A field that is null in the sample is typed null; replace it with the real type, such as Coupon | null. Responses that differ by a kind or type field are best modelled as a discriminated union, which you write once by hand.

For object shapes, both work and compile to nothing at runtime. Interfaces can be extended with extends and can merge when declared twice, which libraries use to let you augment their types, and they often produce clearer error messages. Type aliases can describe anything, including unions, tuples, mapped and conditional types, and they cannot be reopened after declaration.

A sensible rule is to use interfaces for object shapes and type aliases for unions and computed types, but consistency within a codebase matters more than the choice. Pick the option above that matches your lint rules; the top-level alias for arrays and primitives is always a type, because an interface cannot describe them.

TypeScript types are erased when your code is compiled. Writing const order = (await res.json()) as Order does not check anything; it tells the compiler to trust you. If the API changes or returns an error body, the mismatch surfaces later as undefined errors far from the cause.

For data that crosses a trust boundary, such as API responses, webhooks, form posts and files, validate at runtime with a schema library such as Zod or Valibot and derive the type from the schema, so the validation and the type cannot drift apart. When the API publishes an OpenAPI document or a GraphQL schema, generate types from that contract instead of from a sample: it covers every field, including ones your sample did not contain.

Capture a real response from your browser's network tab or a curl call. Remove secrets and personal data, though this page runs entirely in your browser and never uploads what you paste. Paste it here with a meaningful root name such as Order or InvoiceResponse, copy the result into a types file next to the code that calls the API, then refine literal unions, tuples, records and nullability. When the API changes, paste a fresh response and diff the old and new types with the text diff checker to see exactly what moved. If you are deciding whether TypeScript is worth adopting at all, see TypeScript vs JavaScript.