JSON to TypeScript

Turn JSON into TypeScript in one click

This JSON to TypeScript converter generates ready-to-use interfaces, types or classes from a JSON sample, so you never have to hand-write a type for an API response again. Paste a payload on the left and clean, correctly indented TypeScript appears on the right instantly — copy it, or download it as a .ts file.

It's a fast, free, no-sign-up alternative to wiring up a code generator: a single JSON to TypeScript interface step that runs entirely in your browser, with nested objects, arrays and unions all inferred for you. No file size limits, no daily usage caps, and nothing ever leaves your device.

Interfaces, types or classes — your choice

Use the output toggle to switch between an interface, a type alias, or a class. Interface mode is the default and emits export interface Root { … }; type mode produces export type Root = { … } for codebases that prefer aliases; and class mode declares the fields on an export class. The same JSON drives all three, so you can compare them on your own data in seconds.

You can rename the root, toggle the export keyword on or off, and the choice is remembered for next time — turning this into a flexible TypeScript type generator rather than a one-shape converter. quicktype.io supports this too, but requires you to re-run the full conversion each time you change an option.

Smart inference for nested objects, arrays and unions

The engine walks your JSON and builds a named interface for every object, naming nested interfaces from their keys and singularizing array elements — an orders array becomes Order[]. Identical shapes are de-duplicated to one interface, and arrays of mixed types collapse into a union such as (string | number)[].

Turn on enum detection and repeated string values are inferred as a literal union — a status column of "shipped" and "pending" becomes "pending" | "shipped" instead of a loose string. That precision makes the output feel hand-written, and it's what separates this tool from simpler converters that always emit string for string fields regardless of content.

Optional, null and readonly fields done right

Real API data is messy, so the converter handles it honestly. When you convert an API response to TypeScript, keys that appear in only some items of an array are marked optional with a ?, and you decide how nulls are typed: keep them as an explicit | null union, or flip null → optional to turn zip: string | null into zip?: string.

A readonly toggle prefixes every property with the readonly modifier for immutable models. Together these options let you match your project's strictness instead of fighting the generated TypeScript types from JSON. Most competing tools omit one or more of these options, forcing developers to make manual corrections after generating.

How this compares to quicktype, json2ts, and MakeTypes

quicktype.io is the most full-featured option for multi-language generation — it targets Python, Go, C#, Kotlin, and many other languages alongside TypeScript. That breadth means its TypeScript output sometimes includes quicktype runtime helpers and extra boilerplate you'd need to strip for a clean types-only file. It also processes your JSON on their servers, which matters for confidential payloads. json2ts.com is simpler and generates plain interfaces but lacks enum detection, readonly support, and the null-handling options that production projects need.

MakeTypes generates TypeScript classes with runtime parsing, which is useful if you want built-in validation but adds significant code overhead. This UtiloKit converter generates pure types with zero runtime footprint — just the interfaces or type aliases your code needs, working entirely in your browser with no server upload and no account. For everyday API work where you need types fast and clean, that's the right trade-off.

Private by design — your JSON never leaves the browser

Every conversion happens locally using JavaScript in your tab. Your JSON is never uploaded to a server, stored, or shared — it works offline and is safe for confidential payloads, internal APIs and production data. Bookmark this json to typescript converter and reach for it any time you need types from a sample, fast and for free.

The tolerant parser even accepts JSON-ish input with // comments, trailing commas and single-quoted strings, so you can paste a JavaScript object literal from your editor and still get valid output. No other step needed.

How TypeScript infers types from JSON values

The TypeScript type inference model maps each JSON primitive to a built-in TypeScript type: a quoted string becomes string, a number becomes number, true or false becomes boolean, and null becomes null (or string | null when the key also carries string values in other array items). undefined never appears in valid JSON, so it enters the picture only when a key is absent from some objects in an array — at which point the property is widened to T | undefined and marked optional with ?.

Arrays deserve special attention. A homogeneous array such as [1, 2, 3] produces number[], while a mixed array like [1, "a"] collapses into a union type (string | number)[]. An array of objects is merged: all keys from all elements are collected, keys missing from some elements become optional, and the merged shape is emitted as a single named interface — Order[] rather than an inline anonymous type. This structural merging is what separates a type generator from a naive line-by-line converter.

One important caveat: what the tool generates is a structural snapshot of a single sample payload. The TypeScript compiler trusts the shape you declare; it cannot know that the live API sometimes omits a field, sends it as a different type in an error response, or adds new fields in a future API version. Treat the generated interfaces as a starting point and harden them with optional modifiers and union types wherever your API documentation describes variance.

TypeScript utility types for tightening API interfaces

The TypeScript standard library ships a set of mapped utility types that let you derive new types from generated interfaces without duplicating code. Partial<T> makes every property optional — ideal as the body type for a PATCH endpoint where only changed fields are sent. Required<T> does the opposite, stripping all ? modifiers, which is useful to assert that a fully-hydrated server response always carries every field. Readonly<T> adds the readonly modifier to every property at the type level, preventing accidental mutation of API data in application state.

Pick<T, K> and Omit<T, K> let you carve out subsets of a generated interface. For example, if the server returns a large User interface but a form only cares about name and email, Pick<User, 'name' | 'email'> creates a precise type without touching the original. Conversely, Omit<User, 'passwordHash'> removes a sensitive field from a public-facing type. Record<K, V> covers dictionary-shaped JSON objects where the keys are dynamic — a response like { "en": "Hello", "fr": "Bonjour" } is best typed as Record<string, string> rather than a literal interface with fixed keys.

These utilities compose cleanly with generated interfaces. Generate the base shape once with this tool, import it, then derive the variants your application needs using Partial, Pick, and Omit rather than copy-pasting and editing the interface. That way a single source-of-truth interface stays in sync with the API while specialized request and response subtypes are derived automatically.

Nullable vs optional: knowing when to use string | null vs string?

Two distinct concepts often get conflated when typing API responses: nullable and optional. A field typed as string | null tells TypeScript the key is always present in the JSON, but the server may explicitly send null as its value — for instance, a deletedAt timestamp is null until the record is deleted, then it carries a date string. A field typed as string | undefined, or written as field?: string in an interface, tells TypeScript the key may not appear in the JSON at all. These are structurally different: { deletedAt: null } and {} both satisfy deletedAt?: string | null, but only the first satisfies deletedAt: string | null.

Real API responses often deserve both modifiers at once: coupon?: string | null. The server might omit the field on lightweight list responses (undefined) but send it as null on detail responses when no coupon exists. Collapsing this to just string causes runtime errors when you try to call .toUpperCase() on null; collapsing it to just string? loses the distinction between the server explicitly signalling absence versus the field truly being missing. The NonNullable<T> utility type is the inverse: it strips null and undefined from a union — NonNullable<string | null | undefined> produces string — useful when you have already performed a null check and want to narrow the type for downstream code.

The null-handling toggles in this converter let you decide which convention fits your codebase: keep explicit | null unions for maximum precision, or collapse nulls to optional ? for a less verbose style. Neither is universally correct — the right choice depends on whether your codebase distinguishes between a missing field and an explicitly nulled one, and whether your API documentation defines that distinction clearly.

Runtime validation with Zod — because TypeScript types disappear at runtime

TypeScript is a compile-time tool. When the TypeScript compiler transpiles your code to JavaScript, every interface, type alias, and generic parameter is erased — none of it exists at runtime. This means a correctly-typed interface cannot catch an API that returns an unexpected shape at runtime: if your User interface expects id: number but the server sends id: "abc", TypeScript's type checker accepted the declaration but the running program receives the wrong value with no error thrown.

Zod is the most popular solution to this gap. A Zod schema like z.object({ id: z.number(), name: z.string() }).parse(response) validates the actual runtime value and throws a detailed error if the shape doesn't match — and it simultaneously infers the TypeScript type via z.infer<typeof schema>, so you get both runtime safety and compile-time safety from a single source of truth. The pattern is: generate the initial interface from a JSON sample with this tool, then rewrite it as a Zod schema for production use. io-ts offers the same runtime-plus-type guarantee with a functional programming style built on algebraic types, and is preferred in codebases that already use fp-ts.

For projects that already have a JSON Schema or OpenAPI specification, the companion tools json-schema-to-zod and openapi-typescript can generate Zod schemas or TypeScript types directly from the spec rather than from a sample payload. That gives you types that track the authoritative contract rather than one observed example. Use this JSON-to-TypeScript tool for rapid prototyping and one-off type generation; reach for spec-driven tooling — openapi-typescript for REST, graphql-code-generator for GraphQL, or Prisma's built-in types for database models — when you own or have access to the full API specification.