Practical guide

Generate Kotlin data classes from JSON

Kotlin generation is useful when you have a backend or mobile response and want a first pass at data classes. JSON All-in-One can infer Kotlin model shapes from local JSON, including nullable fields and nested objects.

The generated models do not include serialization-library annotations. Choose and configure your serialization library separately, including any annotations or adapters your application needs.

Use a Kotlin-shaped API example

This mobile feed response includes a nullable nested object, a list, snake_case keys, a key that needs a safer Kotlin name, and a large counter. It gives the generated model enough texture to discuss ?, package names, and numeric policy.

If your sample comes from Android logs or a backend contract, keep the original key names. The generated model may preserve snake_case names and only sanitize Kotlin-reserved words, so any later property renaming needs explicit serializer annotations or mapping code.

Illustrative root-object feed JSONjson
{
  "feed_id": "home",
  "items": [
    {
      "item_id": "post_101",
      "kind": "article",
      "published_at": "2026-09-04T08:30:00Z",
      "author": { "display_name": "Mina", "is_staff": false },
      "read_count": 9007199254740993,
      "class": "featured"
    },
    {
      "item_id": "post_102",
      "kind": "note",
      "published_at": null,
      "author": null,
      "read_count": 12,
      "class": "standard"
    }
  ]
}

Read the data class output

Kotlin exposes Data class and Class style options. Data classes are the natural starting point for immutable-ish response models. The generated fields should make nullability visible: Author? means the value can be null, and String? on a timestamp means the sample did not prove a present non-null date.

After generation, check the top of each Kotlin file before compiling. If a single-file output places imports after a data-class declaration, move those imports to the top or switch to the multi-file output and compile again.

Illustrative Kotlin data class excerpt for the root objectkotlin
package dev.example.feed

data class FeedResponse(
    val feed_id: String,
    val items: List<Item>
)

data class Item(
    val author: Author?,
    val class_value: String,
    val item_id: String,
    val kind: String,
    val published_at: String?,
    val read_count: Long
)

data class Author(
    val display_name: String,
    val is_staff: Boolean
)

Review nullability before it spreads

Kotlin makes nullable types visible, which is helpful only if the sample is representative. A missing object in one fixture may produce a wider type than you want; a single non-null example may produce a narrower type than the API actually allows.

Date/time defaults to string for Kotlin in the current option defaults, with a native option available in the policy controls. If you choose native dates, check the generated imports and add whatever adapter or parsing code your project uses.

JSON signalKotlin review pointDo not overclaim
author: nullAuthor?This does not validate future payloads.
published_at date stringString or native date policyNo serializer adapter is implied.
class keySafe Kotlin identifier such as class_valueAdd serializer mapping if you later rename it.
Large read_countLong or BigIntegerCompile and decode before relying on it.

Add serialization glue explicitly

The Kotlin target does not generate kotlinx.serialization, Moshi, Jackson, or Gson annotations. Add any annotations and adapters required by the serialization library your application uses.

For many teams, the generated data classes are still valuable as a review artifact. You can compare them with the API response, decide whether names and nullability are right, and then add the annotations or mapping layer your project already standardizes on.

Handwritten Kotlin usage sketch for the root objectkotlin
fun renderTitles(feed: FeedResponse): List<String> =
    feed.items.map { item ->
        val author = item.author?.display_name ?: "Unknown author"
        "${item.item_id} by $author"
    }

Workflow checklist

  1. Paste a response that includes nulls, absent fields, nested objects, lists, and awkward key names.
  2. Select Kotlin and choose Data class or Class.
  3. Set the package name and prefer multi-file output if single-file output places imports below declarations.
  4. Review nullability, dates, large numbers, and arbitrary JSON values.
  5. Compile the generated model and separately test JSON decoding if you add a serializer.

Limitations to keep visible

A generated Kotlin model is not an API compatibility guarantee. It reflects the sample. If the backend can add fields, omit fields, send nulls, or change date formats, your consuming code still needs a contract and tests.

Do not rely on serializer behavior until the annotations and decoder behavior have been checked in your project. Compilation alone only proves syntax and imports; it does not prove a JSON round trip.

Generated models and serializer responsibilities

Generate Kotlin data classes from a 240-session mobile checkout response, inspect nullable payment and promotion branches, then build and deserialize the exact generated files with Gradle, Kotlin, and explicit Jackson enum adapters.
Diagram showing generated Kotlin data classes between mobile checkout JSON and handwritten serializer and application policy.
Architecture diagram separating generated Kotlin data classes and inferred nullability from handwritten serializer configuration, enum adapters, validation, and API compatibility policy.