What Are Kotlin Data Classes Used For?

A single line of Kotlin can replace 50 lines of Java. That is not an exaggeration. If you have ever wondered what Kotlin data classes are and why they keep showing up in every Android and JVM project, the answer starts with boilerplate elimination.

Data classes are how Kotlin handles the tedious work of writing constructors, getters, equals(), hashCode(), and toString() methods. The compiler generates all of it from your primary constructor properties.

This article covers how data classes work, what the compiler generates for you, restrictions to watch for, and how they compare to Java Records. You will also find real use cases, serialization patterns, Kotlin Multiplatform considerations, and practical best practices pulled from production projects.

What Are Kotlin Data Classes

A Kotlin data class is a special type of class built specifically to hold data. You declare one by placing the data keyword before class in your declaration, and the Kotlin compiler handles the rest.

That “rest” is a lot. The compiler automatically generates equals(), hashCode(), toString(), copy(), and a set of componentN() functions based on the properties in your primary constructor. All from a single line of code.

Here is what a basic data class looks like:

data class User(val name: String, val age: Int)

That single line replaces what would typically be 40 to 50 lines in Java. You get property declarations, a constructor, getters, structural equality checks, a readable toString() output, and a copy function. Without writing any of it yourself.

The minimum requirement is straightforward. Your primary constructor must include at least one parameter marked as val or var.

According to JetBrains, 95% of the top 1,000 Android apps include Kotlin code, and data classes are one of the most commonly used features in those projects. They show up everywhere: API response models, UI state holders, configuration objects.

DigitalOcean’s Kotlin documentation highlights a concrete example. A Java POJO with five fields required 96 lines of code for getters, setters, equals(), hashCode(), and toString(). The Kotlin data class equivalent? One line.

If you are working on any kind of Android development project today, data classes are probably already in your codebase. They are that fundamental to how Kotlin approaches data modeling.

How Kotlin Data Classes Differ from Regular Classes

The difference between a data class and a regular class comes down to what the compiler does for you. A regular Kotlin class gives you nothing beyond what you explicitly write. A data class auto-generates a full set of utility functions.

Look, the best way to understand this is through behavior.

Create two instances of a regular class with identical property values, and == returns false. The default equals() checks reference identity, meaning it asks whether these two variables point to the same object in memory. Two separate objects with the same data? Not equal.

Do the same thing with a data class, and == returns true. The generated equals() compares property values. Structural equality instead of referential equality.

Here is a quick side-by-side:

The toString() difference alone saves a lot of debugging time. Printing a regular class gives you something like User@3a71f4dd. A data class prints User(name=Alice, age=25). Took me a while to appreciate how much faster that makes log reading.

Meta’s engineering team reported that when migrating their Android codebase, which now exceeds 10 million lines of Kotlin, features like data classes contributed directly to boilerplate removal. Their overall migration saw an 11% reduction in lines of code across the board.

TripAdvisor saw even bigger gains in their Vacation Rentals Owner App. Converting Java to Kotlin cut their code by up to 23%, and data classes were called out specifically as a key factor. A Java class with separate getters, setters, and utility methods shrank from over 50 lines to a single data class declaration.

One thing to keep in mind: properties declared in the class body (not the primary constructor) are excluded from all generated functions. Only constructor parameters feed into equals(), hashCode(), toString(), and the rest. This is by design, but it catches people off guard.

Generated Functions Inside Data Classes

The real power of a Kotlin data class lives in its compiler-generated functions. You write one line. The Kotlin compiler produces five categories of useful methods that you would otherwise code and maintain by hand.

The copy() Function and Immutability

How it works: copy() creates a new instance of your data class with the option to change specific properties using named arguments. Everything else stays the same.

“ val original = User("Alice", 25) val updated = original.copy(age = 26) `

This is how you modify immutable objects without actually mutating them. You are not changing original. You are creating a brand new User with a different age.

If you are building state-driven UIs with Jetpack Compose, this pattern is everywhere. Your ViewModel holds a data class representing screen state. Every update creates a copy with the changed field. Clean, predictable, easy to trace.

But here is the catch. copy() performs a shallow copy. If your data class contains a mutable list, the new instance shares the same list reference. Modifying that list affects both the original and the copy. At least in my experience, this trips up developers more often than any other data class behavior.

Java Records, which arrived in Java 16, do not have a copy() equivalent at all. You have to manually reconstruct the object every time.

Destructuring Declarations with componentN()

The compiler generates component1(), component2(), and so on, matching the order of parameters in your primary constructor.

This lets you do things like:

` val (name, age) = User("Alice", 25) `

Where destructuring gets useful:

• Unpacking data inside for loops over maps: for ((key, value) in map)

• Lambda parameters where you want named access to each field
• Quick variable extraction without chaining property calls

The fragility problem: component functions are tied to parameter position, not name. Reorder your constructor parameters, and every destructuring statement in your codebase silently breaks. No compile error. Just wrong values assigned to wrong variables. Your mileage may vary on how dangerous this is, but on larger teams it is a real risk.

equals(), hashCode(), and toString()

equals() compares all primary constructor properties. Two data class instances with identical values are considered equal, period.

hashCode() is derived from the same properties, so equal objects always produce the same hash. This makes data classes safe to use in hash-based collections like HashMap and HashSet.

toString() gives you a human-readable representation. No more guessing what is inside an object during debugging.

You can override any of these manually if the generated behavior does not fit. The compiler will respect your explicit implementations and skip generation for those specific functions.

Requirements and Restrictions for Data Classes

Data classes have rules. Break them and the compiler will tell you, but it helps to know them upfront so you are not refactoring later.

Primary constructor: Must have at least one val or var parameter. A data class with an empty constructor will not compile.

Class modifiers: Data classes cannot be abstract, open, sealed, or inner. They are always final, which means you cannot subclass them.

This is a deliberate design choice. The generated equals() and componentN() functions rely on a fixed set of properties. Allowing inheritance would break those contracts.

Body properties are excluded: Only properties declared in the primary constructor participate in generated functions. Anything you add inside the class body gets ignored by equals(), hashCode(), toString(), copy(), and destructuring.

` data class Person(val name: String) { var age: Int = 0 // excluded from all generated methods } `

Two Person instances with the same name but different age values would be considered equal. This surprises a lot of people.

JVM compatibility: If you need a parameterless constructor (required by some frameworks), you have to provide default values for every property in the primary constructor. Kotlin’s official documentation specifically calls this out for JVM interoperability.

Interface support: Data classes can implement interfaces freely. This is one area where they are actually more flexible than Java Records, which cannot extend any class at all (they implicitly extend java.lang.Record).

When building within a broader software development process, understanding these restrictions early saves you from hitting walls during code refactoring later.

Kotlin Data Classes vs Java Records

Java Records landed as a preview in Java 14 and became stable in Java 16. Both features solve the same problem: cut the boilerplate out of data-holding classes. But they make different tradeoffs.

Immutability is the biggest philosophical split. Java Records enforce it. Every field is final, no exceptions. Kotlin data classes give you the choice between val (immutable) and var (mutable), which is more flexible but also means you can shoot yourself in the foot.

The copy() function is the most practically significant difference for daily work. Without it, modifying a single field in a Java Record means reconstructing the entire object manually, passing every field through the constructor again. On a record with eight or nine fields, that gets tedious fast.

Kotlin’s named arguments make this even smoother. In Java, without named arguments, you are counting constructor positions. Pull request reviewers cannot easily tell which value maps to which field without IDE hints.

Stack Overflow’s 2024 Developer Survey reported that Kotlin had a 58.2% developer satisfaction rate, ranking it among the top five most-liked languages. Java sits considerably lower at 44%. A lot of that satisfaction gap comes from quality-of-life features like data classes.

For teams running mixed Kotlin and Java codebases, there is good news. Since Kotlin 1.5, you can annotate a data class with @JvmRecord to compile it as an actual Java Record on the JVM. This gives you interoperability when you need it, while keeping the Kotlin syntax and features you prefer during development.

Kotlin data classes existed for five years before Java Records shipped. That head start matters because the Kotlin ecosystem (serialization libraries, Android frameworks, multiplatform tooling) was built with data classes in mind from the start.

Common Use Cases for Data Classes

Data classes show up in almost every layer of a Kotlin project. Here is where they do the most work.

API Response Models

Most Kotlin projects that talk to a RESTful API define their response structures as data classes. Libraries like Kotlinx Serialization, Moshi, and Gson all work naturally with them.

` @Serializable data class ApiUser( val id: Int, val name: String, val email: String ) `

The generated equals() and toString() make testing and debugging API responses straightforward. TripAdvisor's engineering team specifically mentioned using data classes with Retrofit to create readable API models in their Android apps.

State Management in Android

Jetpack Compose and ViewModel patterns rely heavily on data classes as state holders.

A typical setup: your ViewModel exposes a data class representing the entire screen state. Every user action produces a copy() with the relevant field changed. Compose detects the new object through structural equality and recomposes only what changed.

Google reports that 70% of the top 1,000 apps on the Play Store are written in Kotlin, and state management through data classes is a core pattern across most of those projects.

Domain Entities and DTOs

Clean architecture patterns often use data classes at multiple levels:

• Data transfer objects between network and domain layers
• Domain models representing business concepts
• UI models tailored to specific screen needs

The copy() function makes layer-to-layer transformation clean. Pull a network DTO, map it to a domain model, then create a UI model from that. Each step can be a copy() with the fields adjusted for the target layer.

Configuration and Event Objects

Data classes work well for settings objects and event payloads. You get structural equality for free (which matters when checking if configuration changed) plus readable logging through the auto-generated toString().

Forbes shares over 80% of its business logic across iOS and Android through Kotlin coroutines and shared data models (JetBrains Multiplatform Survey 2024). Data classes sit at the center of that shared layer, defining the structures that both platforms consume.

When Not to Use Data Classes

Data classes are not the right tool for everything. Knowing when to skip them matters just as much as knowing how to use them.

Classes with Complex Behavior

If your class has more methods than properties, it is probably not a data class. Data classes exist to hold data. When business logic dominates, a regular class gives you more control.

The generated equals() compares all primary constructor properties. For entity classes with database IDs, that is often wrong. Two users pulled from different queries might have the same ID but different timestamps. You want equality based on ID alone, not every field.

Overriding equals() on a data class works, but at that point you are fighting the abstraction instead of using it.

Large Constructor Parameter Lists

More than six or seven constructor parameters is a warning sign. Not because data classes cannot handle it (they can), but because it signals a design problem.

A data class with twelve fields generates a copy() function that is painful to read and a destructuring declaration that no one will use correctly. The componentN() ordering becomes impossible to remember.

Split it. Extract related properties into smaller data classes and compose them. Your future self will thank you during code review.

Inheritance Hierarchies

Data classes are final. They cannot be extended. If your model requires a parent-child class structure, sealed classes or sealed interfaces are the better fit.

` sealed class Result { data class Success(val data: String) : Result() data class Error(val message: String) : Result() } `

This pattern gives you the data-holding benefits of data classes within a type hierarchy. Kotlin’s sealed classes pair naturally with when expressions for exhaustive pattern matching.

The LogRocket engineering blog specifically flags that mixing inheritance with data classes causes compiler conflicts with componentN() functions and breaks the “final” contract that data classes depend on.

Data Classes with Kotlin Serialization Libraries

Serialization is where data classes earn their keep in production code. Almost every Kotlin project that talks to a server or stores structured data locally uses data classes as its serialization layer.

JetBrains’ Developer Ecosystem Survey 2023 confirmed that kotlinx.serialization remains one of the top two Kotlin libraries for the fourth consecutive year, alongside kotlinx.coroutines.

| Library | Approach | Multiplatform Support | Best For | | | | | | | Kotlinx Serialization | Compiler plugin, no reflection | Full (JVM, JS, Native) | KMP projects, type safety | | Moshi | Codegen or reflection | JVM only | Android, Retrofit | | Gson | Reflection-based | JVM only | Legacy Android projects |

Kotlinx Serialization and Data Classes

The setup is minimal. Add the @Serializable annotation to your data class, and the compiler plugin generates the serialization logic at compile time. No reflection involved.

` @Serializable data class Article(val id: Int, val title: String, val published: Boolean = false) `

Default parameter values are respected during deserialization. If a JSON payload omits the published field, the data class uses false. Reflection-based libraries like Gson often ignore Kotlin's default values, which causes subtle bugs.

Spring Boot 4.0 now includes a native kotlinx.serialization starter, according to the State of Kotlin 2026 report. Around 27% of Spring developers have used Kotlin in their projects.

Moshi and Gson Gotchas

Gson bypasses Kotlin constructors entirely. It uses reflection to set field values directly, which means your val properties, default values, and null safety checks? Ignored.

Moshi with its codegen adapter handles Kotlin better. It respects constructors and default values when you use the @JsonClass(generateAdapter = true) annotation.

ProGuard and R8 considerations: on Android, code shrinking can strip serialization metadata. Kotlinx.serialization ships with its own ProGuard rules. Gson and Moshi need manual keep rules for data classes used in app deployment builds, or your production APK will crash on deserialization.

Data Classes in Kotlin Multiplatform Projects

Kotlin Multiplatform (KMP) usage more than doubled in a single year, jumping from 7% to 18% among respondents in JetBrains’ Developer Ecosystem surveys between 2024 and 2025. Data classes are the backbone of shared code in these projects.

Shared Data Models in commonMain

The typical KMP architecture places data classes in the commonMain source set. Both Android and iOS targets consume them directly.

• Network response models defined once, used on every platform
• Domain entities shared across Android, iOS, desktop, and web targets
• Configuration objects that stay consistent regardless of platform

Forbes shares over 80% of its business logic across iOS and Android using KMP, with data classes defining the structures both platforms rely on (JetBrains case study).

Google Workspace now runs KMP in production for the Google Docs iOS app. Duolingo ships weekly to over 40 million users with KMP features. These are not experimental projects.

Swift Interop and What Gets Generated

The old way: Kotlin compiled to Objective-C headers. Data class properties became awkwardly named methods. Swift developers hated working with them.

The new way: JetBrains is building direct Kotlin-to-Swift export, with the first public release targeted for 2025. This will generate clean Swift APIs from your Kotlin data classes, dropping the Objective-C bridge entirely.

Until Swift export is fully stable, data classes still work through the Objective-C layer. The generated code is functional but does not feel native to iOS developers. Keeping data class property names short and descriptive helps readability on the Swift side.

For teams evaluating their tech stack for app development, KMP with shared data classes is now a production-proven approach used by companies like McDonald’s, Netflix, and Shopify.

Best Practices for Kotlin Data Classes

These are patterns that hold up across real projects. Some are from the official Kotlin documentation. Others come from watching things break in production.

Prefer val Over var

Immutable properties by default. Always.

Using val in your primary constructor means the data class instance cannot be modified after creation. Combined with copy(), this gives you safe state transitions without side effects.

JetBrains’ research shows that Kotlin’s null safety, which pairs with immutable data classes, has reduced NullPointerException occurrences by up to 30% across projects that adopt both features together.

Keep Constructor Parameters Focused

Rule of thumb: fewer than six or seven parameters in your primary constructor.

Every parameter feeds into equals(), hashCode(), copy(), and destructuring. The more parameters you add, the slower equality checks become and the harder it is to read generated toString() output.

If you need to exclude a property from equality checks, declare it in the class body instead of the constructor. But do this deliberately, not as a workaround for a bloated constructor.

Pair Data Classes with Sealed Classes

This is probably my favorite Kotlin pattern. Sealed classes define the “what can happen” and data classes define the “what data comes with it.”

Exhaustive when expressions on sealed hierarchies with data class branches give you compile-time guarantees that every case is handled. Add a new branch and the compiler tells you every place that needs updating.

Override Generated Methods Only When Necessary

The default equals() and hashCode() implementations work correctly for the vast majority of cases. Override them only when property-based equality genuinely does not fit your domain model.

Common scenario: a data class with a lastModified timestamp. Two objects with the same business data but different timestamps should probably be equal. Move lastModified to the class body, and the generated methods ignore it automatically.

The Kotlin type system already handles most edge cases. Trust the compiler. Write explicit overrides as a last option, not a first instinct. Following solid software development best practices means letting the tools do the work when they are designed to.

FAQ on What Are Kotlin Data Classes

What is a data class in Kotlin?

A Kotlin data class is a class declared with the data keyword whose primary purpose is holding data. The compiler automatically generates equals(), hashCode(), toString(), copy(), and componentN() functions from the primary constructor properties.

How do data classes differ from regular Kotlin classes?

Regular classes use reference-based equality by default and produce unreadable toString() output. Data classes generate structural equality, readable string representations, copy functions, and destructuring support automatically. You write less code and get more functionality.

Can a Kotlin data class be inherited?

No. Data classes are final and cannot be marked as open or abstract. They can implement interfaces, though. If you need a class hierarchy, use sealed classes with data class branches instead of trying to extend a data class directly.

What is the copy() function in a data class?

The copy() function creates a new instance with the option to change specific properties using named arguments. It performs a shallow copy, so reference types like lists are shared between the original and the copy. Not cloned.

How many parameters does a data class need?

At minimum, one. The primary constructor must have at least one parameter marked as val or var. There is no upper limit, but keeping it under six or seven parameters is a good rule of thumb for readability.

What is the difference between Kotlin data classes and Java Records?

Java Records (stable since Java 16) are always immutable. Kotlin data classes support both val and var. Data classes also offer a copy() function and destructuring declarations, neither of which Java Records provide natively.

Do properties in the class body affect equals() and hashCode()?

No. Only properties declared in the primary constructor participate in generated functions. Anything added inside the class body gets excluded from equals(), hashCode(), toString(), and destructuring. This is by design, not a bug.

Which serialization libraries work best with Kotlin data classes?

Kotlinx Serialization is the top choice, especially for Kotlin Multiplatform projects. It uses compiler-generated code instead of reflection. Moshi with codegen works well for Android. Gson functions but ignores Kotlin default parameter values and null safety.

Can data classes be used in Kotlin Multiplatform projects?

Yes. Data classes defined in the commonMain source set are shared across all targets, including Android, iOS, JVM, and JavaScript. Companies like Forbes and McDonald's use shared data classes as the foundation of their cross-platform business logic.

When should you avoid using a data class?

Skip data classes when your class is behavior-heavy with complex methods, when you need inheritance hierarchies, or when property-based equality does not fit your domain. Entity classes with database IDs are a common case where regular classes work better.

Conclusion

Understanding what Kotlin data classes are gives you a practical foundation for writing cleaner, more predictable code across JVM and multiplatform projects. They solve a real problem that Java developers dealt with for decades.

The auto-generated equals(), hashCode(), copy(), and destructuring functions remove repetitive work from your daily workflow. Less boilerplate means fewer bugs and faster iteration cycles.

But data classes are not a universal solution. Know when sealed classes, regular classes, or interfaces fit better. Match the tool to the problem.

Whether you are building Jetpack Compose UI state holders, defining shared models in Kotlin flows, or structuring JSON payloads with Kotlinx Serialization, data classes will likely be involved. Start with val` properties, keep constructors focused, and let the Kotlin compiler do the heavy lifting.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• Tailwind CSS Cheat Sheet - June 9, 2026
• The Stuff Nobody Tells You About Hiring Web Design Services - June 9, 2026
• How to Create a Pull Request in GitHub Easily - June 8, 2026