Use the free JSON to Kotlin Data Classes below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
JSON to Kotlin Data Classes, Ready to Paste
Android and Kotlin developers convert JSON to data classes constantly. An API response arrives, and before the app can display anything, the data needs a shape: a data class with properties in the right order and the right types. Writing these by hand is repetitive, and repetition produces slips: a property with the wrong type, a nested object pasted as a raw string, a list declared with the wrong element type. This tool writes the data classes from your JSON, so the repetitive part is done and the review part is yours.
Paste the JSON, name the root class, and press Convert. The output is a set of Kotlin data classes. Text becomes String, whole numbers become Int, decimals become Double, true and false become Boolean, and arrays become List of the element type. Each property is declared with val, which fits the immutable style most Kotlin codebases prefer for API models.
How the Classes Are Built
Every object in the JSON becomes a data class. The root object becomes the class you named. A nested address object becomes an Address class. An array of orders becomes a List of Order, with the class name singularized from the field name. If two fields would create classes with the same name, the tool numbers the later one so the code still compiles. Rename it to something meaningful once you know what it represents.
Property names follow Kotlin style. A JSON key like zipCode stays zipCode. A key like zip_code becomes zipCode. A key like orderId becomes orderId. This keeps the generated code looking like code a Kotlin developer would write, and it works with the default naming behavior of kotlinx.serialization and Moshi in many setups, since those libraries map between common naming styles or match keys directly.
Types and the Null Problem
Type inference is conservative on purpose. Whole numbers become Int, decimals become Double, and strings stay strings even when they contain digits. An id sent as “1024” in quotes remains a String, because the tool cannot know whether the quotes are meaningful. If your API mixes numeric strings and numbers for the same field, decide on one type in your model and convert at the boundary of your code.
Null values become Any with a question mark, meaning nullable. That is the tool being honest: a null sample says nothing about the real type. Replace Any with the actual type, for example String or Int, as soon as you know it. Empty arrays become a list of nullable Any for the same reason. These two spots are the only places where the generated code needs your knowledge, and they are easy to find because they stand out in the output.
Missing fields are a related question. If a field appears in one response but not another, the property should be nullable with a default value, or your parser should tolerate its absence. Kotlin data classes with default values handle this well with most JSON libraries. Add a default of null to optional properties after generation, and your model will survive the responses that omit them.
Using the Output With Your JSON Library
With kotlinx.serialization, add the Serializable annotation to each generated class and decode with Json.decodeFromString. With Moshi, add JsonClass with generateAdapter set to true, or use the reflective adapter if your project prefers it. With Gson, the data classes work as plain models with no annotations in most cases. The generated code is library-neutral on purpose: it gives you the shape, and you add the one annotation your library needs.
Property naming is the one place where libraries differ. kotlinx.serialization matches JSON keys to property names, applying a naming strategy only if you configure one. If your JSON uses snake_case and your properties use camelCase, either configure the naming strategy or add SerialName annotations. Moshi has a similar story with its naming policy. Check your library’s naming behavior once, then apply the same fix across the generated classes.
A Practical Testing Routine
Convert the largest response you have. A small sample hides nested objects and edge cases. Then test the model against a second, different response from the same endpoint. Look for fields that change type, fields that disappear, and arrays that are empty in one response and full in another. Each variation is a small edit to the model: a nullable type here, a wider number type there, a default value somewhere else.
Watch out for numbers that outgrow Int. User ids, timestamps in milliseconds, and counters can exceed the 32-bit range. If a value is anywhere near two billion, switch it to Long. Watch out for decimals that arrive as whole numbers sometimes: a price of 12.0 may arrive as 12, and a Double property handles both, while an Int property fails on the decimal form. When in doubt, prefer Double for money-like values and Long for large ids.
Privacy
The tool runs fully in your browser. Your JSON is never uploaded, never stored, and never leaves your device. You can convert responses with real user data without worry, though keeping tokens and passwords out of pasted text is always good practice. No sign-up is needed, and the tool is free to use as often as you like.