JSON to Kotlin
Paste a JSON payload and get Kotlin data classes ready for kotlinx.serialization. Optional fields are given a null default so a missing key decodes rather than throwing, and a SerialName annotation is added only where the Kotlin property name differs from the JSON key — which keeps the class readable instead of annotating every single line. Set a package name and it is written at the top of the file.
How it works
Paste a representative JSON sample and the Kotlin declarations appear on the right. The types are inferred from what is actually in the sample, so the more complete your example, the better the result — one array element with an extra field is enough to have that field marked optional rather than missed.
Each object becomes a @Serializable data class for kotlinx.serialization, with optional fields given a null default so a missing key decodes rather than throwing.
A @SerialName annotation is added only where the Kotlin property name differs from the JSON key, which keeps the class readable instead of annotating every line.
Generation runs entirely in your browser — nothing you paste is uploaded.
Frequently asked questions
Why is @SerialName not on every property?
The annotation only does something when the Kotlin property name differs from the JSON key. Adding it everywhere would double the length of the class for no benefit, so it is emitted only where the names actually diverge — for a key like ship-to that becomes shipTo.
Why do optional fields get a default of null?
kotlinx.serialization throws on a missing field unless the property has a default. Giving optional properties a null default means a payload without that key decodes cleanly instead of failing, which is almost always what you want from an API you do not control.
Does this work with Moshi or Gson instead?
The class shape is the same, but the annotations are kotlinx.serialization ones. For Moshi you would swap @Serializable for @JsonClass and @SerialName for @Json; for Gson, @SerializedName. The property types and nullability carry over unchanged.
Why are whole numbers typed Long rather than Int?
A sample cannot tell you the range of a numeric field, and an ID that fits in an Int today may not tomorrow. Long is the safe choice; narrow it by hand where you know the bound.
What happens to a key that is a Kotlin keyword?
Keywords such as class, object, fun and val cannot be used as property names, so they are renamed with a trailing underscore and a SerialName annotation preserves the original key.
Related tools
JSON to Java Class Converter
This JSON to Java converter generates POJOs with Jackson annotations, getters and setters.
JSON to Dart
Turn a JSON sample into Dart classes with fromJson and toJson, ready for Flutter — no build step needed.
JSON to Rust
Turn a JSON sample into Rust structs deriving serde Serialize and Deserialize, with snake_case renaming handled.