Tool StudioTurn JSON into class or struct definitions, in your choice of language
interface Root { userId: number; // JSON key: "user_id" fullName: string; // JSON key: "full_name" isActive: boolean; // JSON key: "is_active" shippingAddress: ShippingAddress; // JSON key: "shipping_address" tags: string[]; orders: Order[]; metadata: Metadata;} interface ShippingAddress { street: string; city: string; zipCode: string; // JSON key: "zip_code"} interface Order { orderId: string; // JSON key: "order_id" total: number; notes?: unknown;} interface Metadata {}Paste your JSON
A real sample response works best — the more fields and nested structure it has, the more complete the generated classes are.
Pick a language and naming convention
Choose from 7 languages, and set field/class naming independently.
Copy the generated code
Nested and array-item classes are all generated together, ready to paste into your project.
Paste a JSON sample and get back real class or struct definitions in the language of your choice — TypeScript, Java, Go, Python, C#, Kotlin, or C++. Nested objects become their own nested classes automatically (an empty {} object still gets a real, empty class, not a skipped field), and an array of objects merges every item's fields into one class, marking anything missing from some items as optional.
You control the naming convention directly — camelCase, PascalCase, snake_case, or CONSTANT_CASE — separately for field names and class names, regardless of what a language's own typical style is. The original JSON key is always preserved for correct serialization (via an annotation, a tag, or a comment, depending on what the target language actually supports), even when the field name in your generated code has been renamed.
One honest scope note: this generates code from a JSON sample, not from an existing class written in another language — there's no attempt to parse arbitrary source code in one language and regenerate it in another (a much bigger, different problem). Everything runs entirely in your browser; nothing you paste is uploaded.
TypeScript, Java, Go, Python, C#, Kotlin, and C++.
Yes — two independent controls: one for field names, one for class names, each offering camelCase, PascalCase, snake_case, or CONSTANT_CASE. This applies regardless of what a language's own typical style is, so you can match your team's actual conventions rather than whatever the tool assumes.
Each nested object becomes its own separate, named class, referenced from the parent class's field — not inlined. The class name is derived from the field name it was nested under (e.g. a "shipping_address" field produces a ShippingAddress class).
It still generates a real class for it — just with no fields, an empty body. Nothing is silently skipped.
It looks at every item in the array and merges their fields into one shared class: a field present in every item is required, one that's missing from some items (or only ever null) is marked optional/nullable. The class describing one item is named from a singularized version of the array's own field name ("orders" -> "Order").
Yes to both — POJO ("Plain Old Java Object") is just what Java developers call the kind of class this generates for Java, and POCO ("Plain Old CLR Object") is the same idea for C#. This tool isn't Java- or C#-specific, but if you searched for either term, this covers it — pick Java or C# as the target language and you'll get a plain POJO/POCO, no framework base class or annotation required to use it.
Same underlying idea — quicktype and its ecosystem (the CLI tool, the "JSON to TS" VS Code extension) are genuinely excellent and this tool doesn't try to replace them for a local, install-once workflow. The difference is this needs no install, no npm, and no editor extension — paste JSON in the browser and copy the result — and gives explicit, independent naming-convention control (field naming vs. class naming, camelCase/PascalCase/snake_case/CONSTANT_CASE) as a first-class option rather than each language's own automatic default.
This is a real Go language requirement, not a limitation of this tool: encoding/json can only populate exported (capitalized) struct fields through reflection — a lowercase or snake_case field would silently never get filled in from real JSON. Go field names always render as PascalCase for this reason, with your actual JSON key preserved in the field's json:"..." tag instead.
Yes — the naming convention only changes what the field is called in your code. The real mapping back to the original JSON key is preserved through whatever mechanism the target language actually supports: a @JsonProperty annotation in Java, a json:"..." struct tag in Go, a [JsonPropertyName] attribute in C#. For languages with no built-in rename mechanism for their default style (TypeScript interfaces, plain Python dataclasses, Kotlin without assuming a specific serialization library, plain C++ structs), a // JSON key: "..." comment marks it instead, honestly, rather than fabricating an annotation that might not match the library you actually use.
Not with this tool — it generates code from a JSON sample, not from parsing existing source code in another language. Understanding a real class definition well enough to regenerate an equivalent in a different language needs a genuine parser for each source language (handling inheritance, generics, annotations, and each language's own quirks) — a much bigger, different problem than this tool solves. If you have a JSON sample of what that class actually serializes to, generate from that instead.
This is a genuinely rare case in real APIs, and this tool takes a simple, honest approach rather than guessing a complex union type: it uses whichever type was seen in the last item that had a non-null value for that field. If you know a field is genuinely polymorphic, you may want to adjust the generated type by hand afterward.
Yes — a field that's literally null, or missing from some items when an array is merged into one class, is marked nullable/optional using whatever the target language's own convention is (a ? suffix in TypeScript, Optional[...] in Python, a pointer in Go, a boxed type in Java, and so on).
No artificial limit — very large or deeply nested JSON just produces more classes, since everything is processed in your browser's own memory.
No — the entire inference and code-generation process runs in your browser. Nothing you paste is sent to a server.
Paste your JSON sample into the input, choose TypeScript as the target language, and pick a root name — the interface (or nested interfaces, for nested JSON) is generated instantly. No install or account needed.
No — those are two different problems. Reading a JSON file is a runtime operation (in Node.js, typically `JSON.parse(fs.readFileSync('file.json', 'utf-8'))`, or importing a `.json` file directly) that happens while your program runs. This tool does the opposite, at a different time: it looks at a JSON *sample* once, ahead of time, and generates a TypeScript interface you can use to type that data going forward — including for the exact value `JSON.parse()` or a file import hands you at runtime.
No — `JSON.parse()` in TypeScript returns `any`, because the compiler has no way to know the shape of arbitrary JSON at compile time. That's exactly the gap generating a real interface from a JSON sample closes: once you have one, you can annotate the parsed result with it and get actual type-checking and autocomplete instead of `any`.
No — it infers types directly from a real JSON example you paste, not from an existing JSON Schema document. If you already have a JSON Schema and want to generate types specifically from that, a schema-aware tool (e.g. json-schema-to-typescript) is a better fit; this tool is for when you have real example data and no schema yet.
Yes — below the generated code, a collapsible section shows a summary ("N classes, M fields total") and a diagram of how the classes reference each other, auto-laid-out from your JSON. There's a "Download as PNG" button to save it as an image.
Yes — a checkbox above the generated code lets you hide the @JsonProperty/[JsonPropertyName] annotation or // JSON key: "..." comment that otherwise appears on renamed fields. It has no effect on Go, since that language's json:"..." tag is required for decoding to work at all, not an optional annotation.
Yes, for Java and C++ — a checkbox switches from direct public-field access to private fields with public getter/setter methods (Java's follows Jackson's own conventions, including the standard isX()/setX() naming for boolean fields). The other 5 languages don't offer this toggle: Go requires exported fields for JSON decoding to work, TypeScript interfaces have no visibility concept at all, and C#/Kotlin's private-field patterns weren't something we could confirm is safe to auto-generate without risking broken deserialization for those languages.
Paste raw Protocol Buffers (protobuf) bytes as base64 or hex and see every field decoded — no .proto schema needed. Shows every plausible interpretation of each field, since the wire format alone can't say which one is correct.
Convert YAML to JSON or JSON to YAML instantly, in either direction, with clear parse-error messages. All conversion happens in your browser.
Format, validate, and beautify JSON data instantly. Minify JSON, fix formatting errors, and validate JSON syntax online. Perfect for developers working with APIs and configuration files.