JSON to TypeScript

About Code Generator

Writes the type definitions for a document in the language that will read it: TypeScript interfaces or Zod schemas, Go structs, Rust serde structs, Python dataclasses, Pydantic models or TypedDicts, C# classes, Java records, Kotlin data classes, Swift Codable structs, Dart classes, C and C++ structs, PHP classes and Scala case classes. The document can be JSON, YAML, XML, TOML, TOON, INI, .env or .properties — it is read into one plain value first, so every format reaches every language.

Records in a list are merged, not sampled. Every object in an array contributes its fields, so a field that some records have and others lack comes out optional, and a field that is a string in one record and null in another comes out as a nullable string. A type built from the first record alone describes the first record; this describes the list.

Objects with the same fields share one type. A billing and a shipping address with identical keys become one definition used twice, and a nested object is named after the key it sat under — singular where the key is a plural list, so items holds an Item.

Each language gets its own conventions rather than one naming scheme forced through all of them: exported PascalCase with json tags in Go, snake_case with serde renames in Rust and Python, PascalCase properties with JsonPropertyName in C#, camelCase with CodingKeys in Swift. Where a field is renamed, the mapping back to the original key is written beside it, so the types decode the document they came from.

Where it helps

• Seventeen language targets from one form, each following the conventions of its own language rather than one naming scheme for all.
• Merges every record in a list, so optional and nullable fields are found rather than guessed from the first entry.
• Reuses one type for objects with identical fields, and names nested types after the keys they sat under.
• Writes the key mappings — Go tags, serde renames, JsonPropertyName, JsonProperty, SerialName, CodingKeys, Pydantic aliases — so the types decode the original document.
• Keeps integers and floats apart, which JSON does not and every typed language does.
• Reads any of the structure formats, XML and .properties included, not only JSON.
• Runs entirely in the browser, so a production payload used as the sample never leaves the machine.

Limits

• One sample is all it knows. A field that is always null here has no type to find, and a number that happened to be whole is written as an integer.
• Strings are strings: a date, a UUID or an enum-like value is not turned into a date type or an enum, because the sample cannot prove it is one.
• A list holding objects and numbers side by side has no single type and comes out as the language's catch-all.
• C structs describe the shape only — memory ownership, parsing and freeing are left to whichever JSON library you use.
• XML attributes and repeated elements go through the same plain-value reading the converter uses, so the types follow that shape rather than an XSD.

Frequently asked questions

Why is a field optional in one type and required in another?

Because the records disagreed. A field is optional when some objects in the same list have it and others do not; if every record had it, it is required. Turn off the optional switch to write every field as required regardless.

How are nested types named?

After the key they sat under, in the language's case convention: shipping_address holds a ShippingAddress. A list is named in the singular, so items holds an Item and categories a Category. Two different shapes that would take the same name are numbered, and two identical shapes share one name.

What does mapping fields to their JSON keys add?

Whatever that language uses to tie a renamed field back to its key: json struct tags in Go, #[serde(rename)] in Rust, [JsonPropertyName] in C#, @JsonProperty in Java, @SerialName in Kotlin, a CodingKeys enum in Swift, fromJson and toJson in Dart, aliases in Pydantic. Without it the field names still follow the language's conventions, but decoding the original document would need the mapping written some other way.

Why did a field come out as any, object or unknown?

It was null in every record, so there was nothing to infer from, or it held values of incompatible types — a string in one record and an object in another. Replace it with the real type once you know what it is.

Does it matter which format the document is in?

Only in what the format can carry. Everything is read into one plain value first, so YAML and JSON give the same types. A .env or .properties file holds only strings, so every field of one comes out as a string.

Related tools

• Schema Generator — Write a JSON Schema, XSD, Avro schema or .proto from a document you already have
• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back
• Structure Formatter — Pretty-print JSON, XML, YAML, TOML, TOON or HCL with a chosen indent

More Structured Formats tools

• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back
• Structure Formatter — Pretty-print JSON, XML, YAML, TOML, TOON or HCL with a chosen indent
• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• Code Generator — Turn a JSON, YAML, XML or other document into TypeScript, Go, C#, Python, Rust and more
• Schema Generator — Write a JSON Schema, XSD, Avro schema or .proto from a document you already have
• Schema Validator — Check a document against a JSON Schema, .proto, Avro schema, XSD or RELAX NG
• Table Viewer — Show the records in a JSON, XML, YAML, TOML or TOON document as a table
• Structure Compare — Diff two JSON, XML, YAML, TOML, TOON or HCL documents by path
• Structure Repair — Fix broken JSON, YAML, XML, TOML, TOON, INI, .env, .properties and HCL, listing every repair
• Structure Minifier — Strip formatting from JSON, XML, YAML, TOML or TOON
• Path Finder — Select nodes with JSONPath or XPath
• Protobuf & Avro Decoder — Read protobuf wire bytes and Avro container files without their schema
• Expression Evaluator — Reduce a JSONPath or XPath match to a single answer