From JSON response to safe TypeScript types

Start with representative data

Type inference is only as complete as the sample. Include empty arrays, nullable properties and multiple variants when possible so a generator can see the shapes your frontend must handle.

Separate static types from runtime validation

TypeScript types disappear at runtime. They help editors and builds, but cannot prove that a network response is valid. Use a runtime schema such as Zod at untrusted boundaries, then infer the TypeScript type from that schema when appropriate.

• Generate interfaces for developer ergonomics.
• Validate external input before trusting it.
• Model nullable and optional fields deliberately.
• Keep API DTOs separate from UI view models.

Review generated unions

Mixed arrays can produce broad unions. That output is safer than silently choosing the first item, but it may indicate inconsistent source data that deserves a backend contract.

Read a generated type alongside its evidence

Run this fixture through JSON to TypeScript. The generated Root interface describes only the values actually present. The null avatar produces the type null, while an empty roles array produces unknown[]. Neither value tells the generator what future responses may contain.

If the API contract allows avatar to hold a URL and roles to contain strings, the reviewed interface should say string | null and string[]. A property that is sometimes missing needs a question mark; a property that is always present but may be null needs a nullable union. Those are different contracts and cannot be inferred from this one response.

{"id":42,"avatar":null,"roles":[]}

export interface Root {
  id: number;
  avatar: null;
  roles: unknown[];
}

export interface User {
  id: number;
  avatar: string | null;
  roles: string[];
  displayName?: string;
}

Treat inference as a draft, not a contract merger

XXF walks nested objects and names interfaces from property keys. Mixed object arrays can expose repeated interface names; review and rename those declarations before compilation. The tool does not infer discriminated unions, API version guarantees or all optional fields from a production dataset. A successful conversion is not a successful TypeScript build.

For untrusted responses, start with unknown at the boundary and validate against an explicit runtime schema. Test a missing field, an unexpected null and the wrong primitive type. Confirm the schema rejects those cases before letting a cast give the editor confidence that runtime data has not earned.

• Compile the generated declarations in the consuming project
• Confirm optional and nullable fields with the API owner
• Give repeated nested shapes distinct names
• Add runtime validation before reading external data