JSON Tools New Tool

Free Online JSON to Code Generator

Turn any JSON document into TypeScript interfaces, a JSDoc typedef, Python dataclasses or TypedDicts, or Go structs with json tags. Every item of an array is read rather than only the first, so a key that is missing from some items becomes optional instead of wrongly required, and repeated shapes are reused.

Free Forever Nothing Uploaded Four languages Many files at once

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

JSON to Code Generator Your file is read inside this tab. Nothing is uploaded anywhere.

Drop the JSON files you want types for Or paste a response below. An array of records works best, because every item is read. Choose files Up to 15 MB per file. Nothing is uploaded.

Or paste it

Reading Allow comments, as config files use

Write it as Top name

Reading the data A key missing from some items is optional A null value means the field can be empty Reuse one type for identical shapes Objects keyed by id become a dictionary

Writing the code Indent Add export, and a package line for Go Go: pointers and omitempty for optional fields Use any rather than unknown

0 types 0 fields 0 optional 0 levels deep

The code

0 characters 0 lines 0 B

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

How to Generate Types From JSON

A few steps, and nothing is uploaded.

Paste the response, or drop the files An array of records is ideal, because every item is read and the differences between them are what make the types correct.

Choose the language TypeScript interfaces or type aliases, a JSDoc typedef for plain JavaScript, Python dataclasses or TypedDicts, or Go structs with json tags.

Check the optional fields The table lists every field, its type and whether it was missing from some items. That is the part a single example gets wrong.

Copy it into your project Nested objects already have their own named types. Several files download as one zip.

What to Know About Generated Types

Where a single example lies, and what the generator does about it.

Every item of an array is read, not just the first. This is the whole difference between a generated type that works and one that breaks in production. If the first record happens to carry an optional field and the next ninety nine do not, a generator that looks at one example declares that field required, your code trusts it, and the failure arrives later with real data. Here all the items are merged and a key that is absent from any of them is marked optional.

A null tells you nothing about the type. It only tells you the field can be empty. So null is not turned into a type of its own; it makes the field nullable, which is what you actually want to know. If a field is null in every single example then there is genuinely no information about it, and it comes out as unknown rather than as a guess.

Identical shapes become one type. A billing address and a shipping address with the same fields do not need two interfaces, so the structure of each object is fingerprinted and a matching one is reused. The name comes from whichever key was seen first, which is occasionally not the name you would have picked, and renaming it afterwards is one search and replace.

Python puts optional fields last, because it has to. A dataclass field with a default value cannot be followed by one without, so optional fields are moved to the end of the class. That changes the field order from the document, which matters if you construct these positionally, so construct them by keyword. TypedDict has no such rule and keeps the original order.

Go names follow Go conventions, not the JSON. A field must start with a capital to be visible outside the package, so closed_on becomes ClosedOn with a json:"closed_on" tag to map it back. Known initialisms are capitalised the way the language expects, so id becomes ID and url becomes URL, which is what a linter will otherwise ask you to do.

A whole number in one example and a decimal in another is a decimal. JSON has one number type and JavaScript cannot tell 4 from 4.0, so a field that only ever holds whole numbers is typed as an integer where the language has one. Seeing a single fractional value anywhere widens it, because the narrower guess is the one that breaks.

Generated types describe your sample, not the API contract. They are a fast and accurate starting point, and they cannot know about a field that appears only on Tuesdays. If the real documentation exists, this is the thing to check against it, which is far quicker than writing it from nothing.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

Four languages TypeScript, JSDoc for plain JavaScript, Python dataclasses or TypedDicts, and Go structs.

Optional keys found All items of an array are merged, so a key missing from some becomes optional rather than required.

Shapes reused Two objects with the same fields share one named type instead of producing a near duplicate.

Proper Go tags Exported names, json tags back to the original keys, and initialisms capitalised as Go expects.

Every field listed A table of field, type and how often it appeared, so you can see what the sample actually proved.

Nothing is uploaded The document is read in this tab, so a response holding real customer records stays put.

About Generating Code From JSON

Writing types by hand from an API response is dull, and being dull is not the problem with it. The problem is that it is quietly error prone in one specific way: you look at one example. The example has fifteen fields, you write fifteen fields, and three months later something fails because one of those fields is absent whenever the order has not shipped yet. Your type said it was always there, the compiler believed you, and nothing checked.

That is why the interesting part of generating code from JSON is not the printing, it is the reading. Given an array of records, the right answer comes from merging all of them: a field present in every item is required, a field present in some is optional, and a field that is a string in one item and a number in another is both. Most generators take the first element and stop, which produces types that are confidently wrong in exactly the way that is hard to debug.

Null is the other subtle one. A null in the sample tells you the field can be empty and tells you nothing at all about what it holds when it is not empty. Treating null as a type produces something useless; treating the field as nullable keeps the one fact you actually learned. And when every example of a field is null, the honest output is unknown, because there is nothing there to work from.

The rest is respecting each language rather than printing the same thing four ways. Go wants exported names with tags mapping back to the original keys, and it wants ID rather than Id. Python dataclasses require fields with defaults to come last, so optional fields have to move, and you should be told that they did. TypedDict does not have that rule and keeps the document order. These are small things, and getting them wrong is what makes generated code feel like something you have to fix before you can use it.

Frequently Asked Questions

Languages, optional keys, nulls and naming.

Because it was missing from at least one item of an array. That is read as evidence that it may be absent, which is almost always correct. The table shows how many items had it, and the switch turns the behaviour off if your sample is incomplete rather than representative.

A null makes the field nullable rather than becoming a type of its own, since it says the field can be empty and nothing about what it holds otherwise. A field that is null in every example comes out as unknown, because there is genuinely nothing to infer.

Because they have exactly the same fields and types, so one named type describes both. The name comes from the first key where that shape appeared. Turn off the reuse switch if you would rather have a separate type for each.

A dataclass cannot have a field without a default after one with a default, so optional fields move to the end. Construct the class with keyword arguments and it makes no difference. TypedDict keeps the original order.

Because that is the Go convention for initialisms, and a linter will ask for it otherwise. The json tag still carries the original key, so decoding is unaffected. The same applies to URL, API, HTTP and a few others.

They describe the sample you gave accurately, which is not the same as describing the API. A field that only appears in rare responses cannot be inferred from data that does not contain it. Use them as a starting point and check them against real documentation if it exists.

Yes. Drop in as many as you like and each gets its own generated file, downloadable together as a zip. The top level type name is the same for each, so rename it if you plan to paste them into one file.