JSON to TypeScript Interface

About the JSON to TypeScript Interface Generator

Generate strict, idiomatic TypeScript interfaces from any JSON sample. Useful when you need to type API responses, configure tRPC inputs, validate localStorage data, or migrate a JavaScript codebase to TypeScript without hand-writing every shape.

The generator infers types from values, handles nested objects, builds named sub-interfaces, merges array-element shapes, supports nullable fields, and offers three declaration styles: strict types, nullable fallbacks, or all-optional. Paste any JSON, get clean code you can drop straight into a .ts file.

Why generate TypeScript interfaces from JSON instead of writing them by hand?

Three pragmatic reasons. First, accuracy under change — when an API returns a real response, the generated interface matches the actual shape, including every field name, type, and nullable spot you might forget by hand. Second, speed — a 200-field API response that takes 30 minutes to type manually generates in one paste. Third, consistency across teams — multiple developers writing the same interface from API docs invariably disagree on optional fields, casing, and nested shapes; generating from a captured response gives one canonical answer. Caveats: generated types lock to the sample data you provided, so a field present only on some responses gets typed as required when it should be optional. Always run the tool on multiple representative responses (success path, empty path, error path) and merge the resulting types, or use the All Fields Optional mode for safety. For production-grade typing, treat the generator as a fast first draft, then audit nullability and union types by hand against your API contract.

How does the tool handle nested objects, arrays of objects, and mixed-type arrays?

Nested objects become their own named interfaces, derived from the field name (camelCase or snake_case becomes PascalCase: address → Address, user_profile → UserProfile). If a name collides with an existing interface that has a different shape, the tool appends a number (Address, Address2, Address3) to keep types distinct. Arrays of primitives become T[] where T is the inferred element type — string[], number[], boolean[]. Arrays of objects become Item[] where Item is a generated interface that merges all fields across array elements; fields present in some but not all elements should be marked optional (use Mark null as nullable mode and supplement by hand). Mixed-type arrays — e.g. [1, "two", true] — become union types: (string | number | boolean)[]. Empty arrays default to unknown[] because the element type cannot be inferred from no data. For complex API responses with deeply nested arrays, generate types, then refine the inferred Item types by hand to add union variants for response variations.

What's the difference between interface and type aliases, and which should I use?

Functionally similar for object shapes, but with key differences. Interfaces support declaration merging — declare interface User { name: string } twice and TypeScript merges them into one interface with both fields. This is useful for extending third-party types (extend Express Request to add user property after auth middleware). Type aliases do not support merging — redeclaration is an error. Interfaces can be extended via extends syntax; types compose via intersection (&) and union (|). Type aliases can alias non-object types (type ID = string | number) and primitive unions, which interfaces cannot. Performance: identical for object types in modern TypeScript. Convention in 2026: most teams prefer interface for public API contracts (extendable, mergeable, IDE shows interface name in hovers) and type for utility types, unions, and computed types. This tool defaults to interface but offers type when you need an alias-style declaration.

How do I handle fields that are sometimes null, sometimes a value, in real APIs?

Real APIs return null for fields that don't have a value yet (lastLogin: null when user has never logged in). TypeScript's strict mode requires you to handle this explicitly. Three patterns offered by this generator: (1) Strict types — if the sample value is null, the type becomes null literally, and any read of the field returns null with no other possible value. This is wrong for fields that are sometimes populated. (2) Mark null as nullable — null fields become T | null where T is unknown, so you can later refine the type. (3) All Fields Optional — every field becomes optional (key?: type), which is too permissive for fields the API guarantees. Production best practice: generate from a response where the field has a real value, then manually edit the type to T | null where you know the field is sometimes null. For better automation, integrate a schema-first tool like tRPC, Zod, or OpenAPI types — these enforce nullable from a contract rather than guessing from a sample.

Can I generate types directly from an API response or do I have to paste JSON each time?

This tool requires you to paste JSON manually — it runs entirely in your browser with no network access, so it cannot fetch from your API. The intended workflow: use your browser DevTools or a tool like Postman / Insomnia / Hoppscotch to capture a real API response, copy the JSON body, paste into this tool, copy the TypeScript output, paste into your codebase. For automated generation from live endpoints, use a server-side tool: quicktype (CLI, install from npm: npm install -g quicktype, then quicktype --src-lang json --lang typescript response.json), json-to-ts npm package for programmatic generation, or schema-first tools like OpenAPI Generator that pull from your spec file. For full-stack TypeScript apps, tRPC eliminates the round-trip entirely — types flow from your server router to your client without JSON-to-type conversion. This tool fills the gap when you need a one-off type for a third-party API or legacy endpoint.

How do I handle TypeScript types for APIs that change over time or have versioned schemas?

Generated types capture a moment in time, but APIs evolve — fields are added, deprecated, renamed, and removed. Three strategies for keeping types current: (1) Manual regeneration on schema changes — when an API change is documented, re-run the generator with a fresh response and diff the output against your current types; useful for low-frequency changes. (2) Schema-driven types — if the API provides OpenAPI, GraphQL, or Protobuf schemas, generate types from the schema instead of a response; tools like openapi-typescript, graphql-codegen, and ts-proto handle versioning by re-running the codegen on every schema commit. (3) Runtime validation — pair static types with runtime schema validators (Zod, Valibot, ArkType) so type mismatches at runtime become explicit errors instead of silent corruption; particularly valuable for third-party APIs you don't control. The combination — generated types for fast iteration plus runtime validation for safety — is the modern standard for production TypeScript apps in 2026.

What's wrong with using any to type API responses — why bother with strict interfaces?

Typing API responses as any is the most common shortcut and the most common source of production bugs in TypeScript codebases. With any, the compiler accepts user.adddress (typo), user.id.toUppercase (id is a number, not a string), and array[1000].name (might be undefined) — all crash at runtime, none are caught at build time. Strict interfaces convert these to compile-time errors that block bad code from shipping. The trade-off is upfront effort: writing or generating types takes minutes that any saves. The payoff scales with team and codebase size — for solo prototypes, any is fine; for shared codebases over 1,000 lines, strict types catch 60-80% of bugs that would otherwise reach QA or production (multiple industry studies including Microsoft's internal TypeScript adoption data). Modern practice in 2026: never use any for external data boundaries (API responses, localStorage, user input, env vars); use unknown plus runtime validation if the shape is genuinely dynamic; use generated interfaces for known APIs.

Can the tool infer string-literal unions (enums) and how do I use readonly or as const?

Yes. Enable the String Enums option (Detect string unions) and the generator inspects fields across all elements of an array of objects; when a field's values form a small, fully-enumerable set of distinct strings, it emits a literal union instead of the loose string type — for example role: 'admin' | 'user' rather than role: string. This is exactly the protection strict TypeScript exists for: with a plain string type, a typo like status === 'activ' compiles fine and reaches production, whereas a 'active' | 'inactive' union turns it into a compile-time error. The Max distinct values control (default 12, clamped 2-50) sets the cutoff — fields with more distinct values than the limit fall back to string, since high-cardinality fields like ids or names are not real enums. Inference only runs on arrays of objects, because a single object gives one sample and one value can never be enumerated. After generating, you have two idiomatic ways to tighten further: add the readonly modifier (readonly role: 'admin' | 'user') so the field cannot be reassigned after construction, useful for API-response DTOs that should be treated as immutable; or, for a constant config object rather than a type, append as const to the literal value (const ROLES = ['admin', 'user'] as const) and derive the union with typeof ROLES[number]. For runtime safety beyond compile-time, pair the union with a validator like Zod's z.enum(['admin', 'user']) so unexpected values from the wire are caught at the boundary.

How does the tool handle very large JSON, big integers, and date strings?

The conversion runs entirely in your browser on a single paste, so performance scales with JSON.parse and DOM rendering — typical API responses (tens of thousands of lines) convert instantly, but multi-megabyte payloads can be slow because the whole structure is walked to infer types; for those, trim to a representative subset or use a CLI like quicktype. On number precision: JSON has a single number type and JavaScript parses every numeric value as a 64-bit float, so integers beyond Number.MAX_SAFE_INTEGER (2^53 - 1) silently lose precision before the tool ever sees them — the generated type is number, but if your API returns 64-bit ids (snowflake ids, database bigints), the server should send them as strings and you should type them as string, or use the bigint type with a JSON parser that preserves it. Date and timestamp fields stay typed as string because ISO-8601 values like 2026-05-29T00:00:00Z are JSON strings, not a Date object; that is correct for the wire format. Convert to Date at the boundary (new Date(dto.createdAt)) and keep the DTO type as string, or use a branded type / Zod's z.string().datetime() to distinguish date strings from ordinary text without lying about what crosses the network.

How does this generator compare to quicktype, json-to-ts, and other JSON-to-TypeScript tools?

quicktype is the most-cited open-source tool with the deepest analysis: it walks multiple JSON samples to infer optional fields, union types from differing responses, and complex polymorphic shapes (one of A or B). It's a CLI with web playground, supports 20+ output languages, and is the right choice for production type generation from large or varying datasets. json-to-ts is a smaller npm package focused only on TypeScript output, simpler but less inference power. Online tools like JSON-Type, Transform.tools, and this one are convenient for one-off conversions without CLI setup. This tool's design favors quick browser use: paste, see output instantly, copy to clipboard, no external network calls — useful when you need a fast first draft for a single response. For team workflows generating types from multiple sample files, switch to quicktype. For schema-first workflows, use openapi-typescript or GraphQL Code Generator. This tool is the right pick when you have one JSON sample, want immediate output, and prefer a private browser-based workflow over installing CLI tools.