JSON to TypeScript

Paste a JSON payload, get TypeScript interfaces — nested, named and merged.

Processed locally — nothing is uploaded

JSON

Root type name

TypeScript

export interface Root {
  ok: boolean;
  users: User[];
  page: Page;
}

export interface Page {
  size: number;
  next: null;
}

export interface User {
  id: number;
  name: string;
  roles: string[];
  last_login: string | null;
  email?: string;
}

Types are inferred from this sample alone: a field every element happens to include is emitted as required, one missing somewhere becomes optional. Check both against what the producer actually guarantees.

About JSON to TypeScript

Array elements are merged rather than sampled: a key absent from any element comes out optional, and conflicting value types become a union with null sorted last. Identically shaped objects share one interface instead of generating duplicates, and property names that are not valid identifiers are quoted rather than mangled.

Hand-writing types for an API response is the chore this removes, and the mechanical parts are exactly the parts people get wrong by hand: which fields are optional, which values can be null, what shape the third level of nesting actually has. The generator walks the payload once and emits an interface per object shape — nested objects become named interfaces, arrays of objects are merged element by element, and two structurally identical objects share a single interface rather than producing near-duplicate declarations to maintain separately.

The merging rules are where the value lives. Across an array's elements, a key that any element lacks is emitted optional, and a key whose values disagree in type becomes a union — so a list where last_login is sometimes a string and sometimes null comes out as string | null rather than whichever the first element happened to show. Empty arrays are typed unknown[] instead of guessed at, empty objects become Record<string, unknown>, and keys like content-type that are not legal identifiers are quoted, not silently renamed.

One limitation is structural and worth planning around: the types describe your sample, not the API's contract. A field present in every element of a short sample is emitted required even if the producer considers it optional; a genuinely required field can look optional if your sample includes a malformed row. Generated types are the fast, accurate first draft — the producer's documentation is the authority on what is actually guaranteed, and the fields worth double-checking are precisely the optional ones.

Learn how this works

A Practical Guide to Everyday Developer Encoding & FormattingHow and when to use Base64, JSON formatting, hashing, JWTs, regex and cron — with free in-browser tools for each task.11 min read

Frequently asked questions

Why is a field optional in the output when the API always sends it?

Because some element of your sample was missing it — the generator only knows what the sample shows. Paste a larger or more representative sample and the inference improves; or, if you know the field is guaranteed, delete the question mark. The reverse error is more dangerous: a field required in your sample may still be omitted by the API someday, and no sample can prove otherwise.

Why do two properties reference the same interface?

They have exactly the same structure, so the generator emits one interface and reuses it — home: Home and work: Home rather than two identical declarations. If the two are conceptually different types that merely coincide today, rename one by hand; that distinction lives in your head, not in the JSON.

How are dates and other string formats handled?

As strings, because that is what JSON contains. JSON has no date type — an ISO timestamp, a UUID and a URL are all just strings on the wire. If you want branded types or Date fields, that transformation belongs in your parsing layer, not in the wire types.

Is my JSON uploaded to generate the types?

No. Everything runs locally in your browser using standard web APIs — your text, files and inputs are never uploaded to a server, so the tool works even offline once the page has loaded.

Pro Tips

→Paste the largest realistic sample you have — optionality and unions are inferred from variety, and a single element proves almost nothing.
→Check the optional fields against the API's documentation; the sample can only show what it happened to contain.
→Chain from the Code Formatter: format or validate the payload first, then send it here — malformed JSON fails fast with the parser's own error.
→Rename the root type to something meaningful before pasting the output into a codebase; a file of interfaces rooted at 'Root' ages badly.
→Watch for unknown[] in the output — it marks arrays your sample left empty, and those are the fields most worth a second sample.

Common Use Cases

•Typing a third-party API response before writing the client code that consumes it.
•Generating interfaces for a webhook payload from the provider's example body.
•Converting a config file's shape into types so the loader can validate it.
•Producing a first-draft schema from a database export or fixture file.
•Checking what shape a payload actually has versus what its documentation claims.

How It Compares

quicktype is the heavyweight in this space — more languages, runtime validators, more options, and correspondingly more to configure. IDE plugins do the same inline for people who have them set up. This covers the everyday case with zero setup: paste, copy, and the payload never leaves the tab — which matters more than usual here, because real API samples routinely contain real customer data.