JSON to Kotlin Data Class — kotlinx.serialization, Gson, or Moshi

Real-world use cases

• Type a Retrofit response without hand-writing the model

  You're calling a third-party REST API from an Android app with Retrofit + Moshi, and the response has 25+ fields in snake_case. Curl it once, paste the JSON here, set the root name to `OrderResponse`, pick Moshi. Every `created_at`-style key gets `@Json(name = ...)` so the converter binds it, nested objects lift into their own classes, and optional fields become `T?`. Drop the output into `OrderResponse.kt`, declare `@GET("orders") suspend fun orders(): OrderResponse`, and you get a fully-typed result instead of a `Map<String, Any?>` you cast your way through field by field.

• Build kotlinx.serialization models for a Ktor service

  You're writing a Ktor backend and want a request and response model for a new endpoint. Paste the sample request body, name the root `CreateOrderRequest`, keep kotlinx.serialization. You get a `@Serializable data class` with `@SerialName` on the renamed fields and the exact imports it needs. Turn on default values so missing keys decode cleanly instead of throwing, and the model is forward-compatible the day a new optional field appears in the payload.

• Catch which webhook fields are actually optional

  A vendor's webhook sometimes includes `cancelled_at` and sometimes omits it. Log a handful of payloads, paste them as a JSON array, and the array-fold detection marks `cancelled_at` as missing in some elements — so it becomes `String?` instead of a non-null field that would crash on deserialization. In your handler a `?.let { }` now cleanly distinguishes "cancelled" from "still active" instead of guessing whether a default value means the field was absent.

• Migrate a Java DTO to an idiomatic Kotlin data class

  You're porting an Android module from Java to Kotlin and a Gson-bound POJO needs to become a data class. Grab a representative JSON response, paste it, choose Gson, and you get `@SerializedName`-annotated `val` properties in a single `data class` — no getters, no `equals`/`hashCode` boilerplate, and `copy()` for free. The new class is a fraction of the line count of the Java original and reads exactly like the JSON it models.

• Replace a Map<String, Any?> with a real type

  Legacy Kotlin does `val data: Map<String, Any?> = parse(body)` and reaches in with casts like `data["id"] as String`, losing every compile-time check and inviting `ClassCastException` at runtime. Capture one representative response, paste it, generate the data class, and replace the map. Now `Int`, `Long`, and `Double` are inferred per field, nullability is explicit, and the compiler catches a renamed key at build time instead of in production.

Common pitfalls

• Pasting a single object and expecting some fields to be nullable. A single object has no missing-key signal, so every field is non-null unless its value is literally null. Nullable inference only kicks in across an array of objects where some elements carry a key and others don't. To explore optionality from one sample, wrap it as `[{...}]`.

• Leaving a money or precise-decimal field as `Double`. The tool infers `Double` for any fractional number, but `Double` is binary floating point and will misrepresent values like 0.1 or a currency total. For money, change those fields to `BigDecimal` after generating — JSON carries no signal that a number needs exact base-10 precision.

• Forgetting the kotlinx.serialization Gradle plugin and runtime. The `@Serializable` annotation needs both the `org.jetbrains.kotlin.plugin.serialization` Gradle plugin and the `kotlinx-serialization-json` dependency; without the plugin the code won't compile. If you only want the plain class, pick the None annotation style instead.

• Deleting an @SerialName / @Json / @SerializedName annotation and expecting binding to still work. The annotation is what maps `site_admin` (wire) to `siteAdmin` (property). Remove it and the serializer will look for a `siteAdmin` key that doesn't exist, leaving the field null or failing to decode. Keep the annotation or configure a global naming strategy instead.

Privacy