Type generation from a sample is inference, not truth. Every generator here reads one document and produces the narrowest type that document supports — a useful first draft and a bad final answer. What each one gets wrong is predictable, so it is documented rather than hidden.
T
Generate developer types
Turn representative JSON into schemas, interfaces, validators, and language types.
A field that happens to be present in your sample is generated as required, even when the API marks it optional. A field that is null in the sample has no inferable type at all. An empty array gives no element type. A number that happens to be whole in the sample generates as an integer even when the API returns decimals. Feed the generator two or three representative documents' worth of shape — including the edge cases — and then widen the result by hand.
Choosing between a type and a validator
TypeScript interfaces, Go structs, and C# classes are compile-time shapes: they describe what you believe the payload is and disappear at runtime. Zod schemas, Pydantic models, and JSON Schema are runtime checks: they refuse a payload that does not match. If the JSON crosses a trust boundary — anything from a third-party API, a webhook, or a user upload — generate the validator, not just the type.
Naming and casing
JSON keys are frequently snake_case while the target language wants PascalCase or camelCase, so each generator applies the idiomatic convention and emits the mapping annotation the language needs — json tags for Go, serde rename for Rust, JsonPropertyName for C#. Keys that are not valid identifiers keep their original spelling in the annotation so the wire format stays intact.