JSON to Kotlin Data Class

Convert a JSON object to idiomatic Kotlin data class definitions with proper types, nullable fields, and nested classes.

JSON Input

Root class name

or drop a file here

Kotlin Output

Kotlin data classes appear here…

About JSON to Kotlin Data Class

Kotlin data classes provide a concise syntax for model classes with auto-generated equals(), hashCode(), and toString(). This generator maps JSON types to Kotlin types: strings → String, integers → Int, decimals → Double, booleans → Boolean, nulls → Any?, arrays → List<T>, and nested objects → nested data classes. Field names are converted from snake_case to camelCase.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Generating data classes from an API response instead of typing them out.
Producing a starting model for an endpoint with no published schema.
Checking how a payload's nesting maps onto Kotlin nested classes.
Creating models for a test fixture that match production shapes.
Comparing generated classes across two API versions to spot a break.

Frequently Asked Questions

How are types inferred from JSON?: A whole number becomes `Int`, a fractional one `Double`, `true`/`false` becomes `Boolean`, a string `String`, and a nested object becomes its own data class named after the key. JSON has one number type, so 5 and 5.0 are indistinguishable — check any field that could be either.
What happens with a mixed or null-containing array?: Every element is examined rather than just the first, so `[null, 1, 2]` gives `List<Int?>` — a nullable *element*, not a nullable list. Taking the type from element zero is the classic bug here, and it produces code that crashes on the second item.
Why is a field Any?: Because the sample gave no evidence: a field that is `null` everywhere in your example has no inferable type. Replace `Any` by hand — the generated class is a starting point built from one sample, not a schema.
Do I need @SerialName?: Whenever the JSON key is not a valid or idiomatic Kotlin name. `user_id` becomes `userId` in the class, so the serializer needs `@SerialName("user_id")` to map it back — with kotlinx.serialization, or `@Json(name = ...)` with Moshi.
Should every field be nullable?: No — that pushes null checks into every call site. Make a field nullable only when the API genuinely omits it, and give optional fields a default instead, so `kotlinx.serialization` can fill them in when the key is absent.
Should the generated class be a data class?: Usually yes — it supplies equality, hashing, copying and a readable `toString` for free, which is exactly what a DTO needs. A plain class is right only when you need custom equality semantics.

Common errors and gotchas

Accepting inferred nullability, which one sample cannot determine.
Letting a whole number become Int when another response returns a fraction.
Shipping generated class names derived from keys, which rarely read idiomatically.
Assuming serialisation annotations are added, when key names that are not valid identifiers need them.
Treating a large integer as Long or Int when the source is a JSON number that already lost precision.