JSON to TypeScript Converter

The converter maps JSON types to TypeScript types as follows: JSON strings become string; JSON numbers become number (with a warning about lack of integer-specific types in TypeScript); JSON booleans become boolean; JSON null becomes null or undefined depending on your configuration (with null asserting the value can be null, meaning the value must be explicitly set, while undefined means the property may be absent); JSON arrays become Array<T> or T[] where T is the deduced item type (mixed arrays use union types); JSON objects become nested interfaces with PascalCase names derived from the context. The converter also detects: enum candidates (string fields that always have the same set of values become string literal union types), readonly candidates (fields unchanged across samples), and optional fields (properties present in only some array elements).

Both interface and type alias have their advantages. Interface is preferred for object-shaped types because: it can be extended (extends keyword for inheritance), it supports declaration merging (useful when augmenting existing types), it produces clearer error messages in most compilers, and it is the conventional choice for API data shapes. Type alias (type) is preferred when you need: union types (A | B), intersection types (A & B), mapped types, conditional types, or to name primitives and tuples. For API data modeling (the most common use case), interface is generally the better choice because API response shapes are typically object types that benefit from extension capabilities. However, if you plan to combine your generated types with union or conditional types, type alias may be more flexible. The converter can generate either form based on your preference.

The converter uses a distinction between optional (may be absent) and nullable (present but may be null) based on the JSON sample data. If a property appears in some objects but not others in your sample array, it is marked optional with the ? modifier in TypeScript (address?: string). If a property sometimes holds null, the type becomes a union with null (address: string | null). If a property is both optionally present AND can be null when present, it becomes address?: string | null. For projects using strict null checks in tsconfig.json (highly recommended), these distinctions are crucial: optional properties must be checked with if (obj.address) or optional chaining (obj.address?.city), while nullable non-optional properties must be checked even when the property is definitely present in the object.

Yes, you can paste multiple JSON objects in an array to help the converter detect variations. When you provide multiple samples: properties present in all objects are marked as required, properties present in only some objects are marked as optional with ?, properties with different types across samples are marked with union types, and array item types are determined from all items across all samples rather than just one. For example, with one sample {name: string, age: number} you get all required fields; with two samples where one has {name: string, email: string} and the other {name: string, phone: string}, the converter produces name: string (required), email?: string (optional), phone?: string (optional). This is particularly useful for APIs where different endpoints or response conditions return different subsets of fields.

The generated types can be used with HTTP client libraries for type-safe API calls. With fetch: define the response type and use await response.json() as ApiResponseType. With axios: use generics like axios.get<ApiResponseType>(url). With React Query or SWR: pass the type to the hook useQuery<ApiResponseType>(key, fetcher). With GraphQL codegen: the generated types can serve as a base for your GraphQL schema types. After copying the types into your project, you get: compile-time errors if you access non-existent properties on API responses, IDE autocompletion for all response fields with inline documentation, type-safe refactoring (rename a field once and all usages update), and confidence that matches the actual API structure. Remember to update your types when the API changes — the converter makes this quick by just pasting the latest JSON sample.