JSON → Types
Generates TypeScript interfaces, Pydantic models or Go structs from pasted JSON.
Root type name
Language
What this tool does
Paste a JSON — typically an API response — and get ready-to-use type definitions in the language of your choice: TypeScript interfaces, Pydantic (Python) models or Go structs. The tool looks at the real structure of the pasted value (keys, types, nesting) and infers the most precise type that describes that exact shape, including the edge cases a shallow conversion usually ignores.
Array merging that looks at every item
When the pasted JSON is a list of objects (e.g. order items, search results), the tool examines EVERY item before deciding each field's shape — not just the first one. A field that shows up in some items and is missing in others becomes optional ("?" in TypeScript, "= None" in Python, a pointer in Go); a field present in every item, even if sometimes a number and sometimes text, becomes a union of the observed types. This is the most visible difference between this tool and a shallow converter, which usually only looks at the first item of the list.
"Missing" and "null" are different things
A field can be missing for two very different reasons: the key never appeared in the JSON (optional) or the key appeared with the value null (nullable). TypeScript and Python distinguish the two with full precision ("field?: string" vs. "field: string | null" in TypeScript). Go is the exception: the language's standard JSON package doesn't distinguish the two cases in practice, so both use the same pointer convention — a limitation of the language itself, not of this tool.
Field naming per language
By default, the generated field name is exactly the original JSON key — the safest way to guarantee the type matches the real data. The "Convert field names" option renames to each language's idiomatic convention (camelCase in TypeScript, snake_case in Python, always PascalCase in Go). In Python and Go the original key is never lost: Python uses a serialization alias and Go uses the struct tag — both keep correctly reading the real JSON after renaming. TypeScript has no such mechanism (an interface is just a structural shape, with no serialization logic), so converting there assumes the keys are already normalized elsewhere in your code.
Known limitations
Type name singularization (e.g. "addresses" → "Address") uses an in-house English heuristic — irregular plurals ("children", "people") aren't recognized and the name comes out the same as the plural. Very large numbers already lose precision in the browser's own JSON.parse, before ever reaching the tool. Go has no native union type: a field with more than one observed type becomes "any", with a comment listing the possible types. In Python, a field that's only optional (never actually observed as null) uses the same syntax as a nullable field — the language has no simple idiomatic way to require the key while still allowing a default. The output assumes Python 3.10+ with Pydantic v2 and Go 1.18+.
Frequently asked questions
Because the key was missing in at least one item of the list — optional means "may not be sent", not "may be null". See the "Missing and null are different things" section above.
Two different keys in your JSON produced the same type name (e.g. an "address" field and an "addresses" field in the same object). The tool resolves the collision automatically, first trying to prefix with the parent type's name, then a number — it never overwrites an already-defined type.
Because a TypeScript interface isn't executed — it only describes the shape of the value. Renaming the field without also transforming the real data would make the type lie about the actual JSON. Python and Go have an alias/tag mechanism for this; TypeScript, by nature, doesn't.
A numeric field only becomes an integer if EVERY observed value is an integer; a single value with a decimal point already decides "float" for the whole field. TypeScript doesn't make this distinction ("number" covers both) — it only shows up in Python (int/float) and Go (int64/float64).
Yes — type inference runs entirely in your browser. Nothing from the pasted JSON is ever sent to a server.
Either because no non-null value of that field was ever observed (it was always null), or because the field has more than one possible type and the output language can't express that union (Go's case, which also gets a comment listing the observed types).