JSON to Code
Generate TS / Go / Java / C# / PHP type definitions from a sample JSON
Generating type definitions from JSON: what it saves, and where you must edit by hand
It infers structure from a sample
The generator reads one sample JSON document and infers types from the values, then emits type definitions for the target language. By nature this is induction: it guesses a general structure from a limited sample. The reliability of the result depends entirely on how representative the sample is, so there is a class of problems it cannot solve in principle and you must correct manually.
Five places you must confirm by hand
| JSON phenomenon | Common problem in output | How to fix |
|---|---|---|
"count": 0 | Inferred as a number; cannot tell if the field may be null | Add the nullable marker per the API docs |
"tags": [] | An empty array cannot infer its element type, often producing any[] / unknown[] / interface{} | Specify the element type by hand, or use a sample that contains elements |
"price": 9.9 | Cannot tell float from int; Java/C# cannot distinguish int from long | Pick the concrete numeric type by business range |
"createdAt": "2026-01-15T08:00:00Z" | Produces a string type, not a date | Decide per language convention whether to convert to a date object or keep the string |
| A field missing from the sample | The field is entirely absent from the output | Add it — this is the most common and most dangerous omission |
The third row deserves special attention: many JSON serializers emit int64 as a number, but JavaScript represents integers precisely only up to 253-1, and Java's int is only 32 bits. If a field like an amount or an ID is given too narrow a type, it will overflow or lose precision at some large value in production. Do not decide the type width from the numeric range seen in the sample.
Naming and structure vary by language
JSON keys conventionally use camelCase, and each language's target style differs, so the generator converts:
| Language | Type-name convention | Field-name convention | Common extras |
|---|---|---|---|
| TypeScript | PascalCase interface | Keep camelCase | Optional fields use ?, unions use | |
| Go | PascalCase struct | Export requires an initial capital, so converted to PascalCase | Needs a JSON tag to map back to the original key |
| Java | PascalCase class | Keep camelCase | Lombok annotations, @JsonProperty mapping |
| C# | PascalCase class | Converted to PascalCase | Needs [JsonPropertyName] to map back |
| PHP | PascalCase class | Keep camelCase | Can add type declarations and defaults |
The Go and C# rows are the easiest to forget in practice: after capitalizing the first letter, if there is no explicit field-mapping annotation, the serialized key names will not match the API contract and the symptom is "every field comes back as a zero value". Always check that those annotations exist after generation.
Nested structures and type reuse
When the same structure appears several times in the sample, the generator has two strategies: emit one copy at each location (duplicated, simple but verbose), or extract a shared type (which requires judging whether two structures are truly the same entity).
Automatic merging is risky: two structures may happen to have identical fields but different meanings (for instance "user address" versus "shipping address"), and merging them means a new field on either side affects the other. So review the tool's suggested type merges by hand rather than accepting them wholesale.
Arrays and union types
When array elements have inconsistent types in the sample, the generator either emits a union type (TypeScript's (string | number)[]) or falls back to a loose type. A union type usually signals a flawed API design (one field carrying two types); confirm the backend's intent instead of tolerating it in the type definition.
When it helps and when it does not
- Good for: a quick start when integrating a third-party API, turning a captured debug response into a usable type, writing a one-off processing script for existing JSON, and comparing the structure of two API responses.
- Not good for: being the sole source of the contract. A proper contract comes from a semantic spec like OpenAPI, JSON Schema, or Proto, and types should be generated from that spec rather than reverse-engineered from one capture. Fields absent from the sample, nullability, and value ranges are all invisible to a capture.
- Note: very large or deeply nested JSON produces extremely verbose output; trim it to the subtree you need before generating.
Generation runs locally in your browser; the API response is never uploaded, which matters when the response reveals internal interface structure.
FAQ
Is the type inference accurate?
It is based on the sample you provide. The array type is inferred only from the first element; if that field is null in the sample, it falls back to a generic type such as Object or interface{}. Complete the sample before generating.
Can it generate constructors or validation annotations?
This tool only generates plain type or class skeletons without business logic. Add annotations or methods on top of the result if you need them.