Lintify Logo
Lintify
Code Generators

JSON to Java POJO Generator

Generate Java POJO classes from JSON. Pick Jackson or Gson annotations, configure package name, and download ready-to-compile classes.

JSON input
1
Java POJO
Output will appear here…

Generate Java POJOs from JSON

Mapping JSON to Java classes by hand is one of the most tedious parts of writing a Java backend. Every API response needs a corresponding class, every field needs the right type, and every field needs a Jackson or Gson annotation to preserve the original JSON key (because Java convention is camelCase but JSON keys are usually snake_case). Lintify does all of that automatically — paste a sample JSON, pick your library and package, and download ready-to-compile Java classes.

Each generated class has private fields with public getters and setters, which is the standard JavaBean convention. Jackson's@JsonPropertyannotation (or Gson's@SerializedName) is added to every field so that the JSON key is preserved during serialization and deserialization. The result is a class you can use directly with ObjectMapper.readValue() orGson.fromJson().

Jackson or Gson?

Jackson is the de facto standard in Spring Boot and most enterprise Java codebases — it ships with Spring Boot starter web, has the best performance of any Java JSON library, and supports every JSON feature you will ever need. Pick Jackson if you are starting a new project or if you are not sure.

Gson is lighter and easier to configure for small projects. It is the right pick if you are writing a non-Spring application, if you need to keep your dependency footprint small, or if you are integrating with an existing codebase that already uses Gson. The generated POJOs are structurally identical between Jackson and Gson — only the annotations differ, and you can convert between them with a find-and-replace.

Number types and BigDecimal

Integers become int (or Integerfor nullable fields), large integers becomelong, and decimals becomedouble. For financial data, replacedouble with BigDecimal after generation — double is not safe for money because it cannot represent decimal fractions exactly.BigDecimal is slower but correct, which is the right tradeoff for money.

Nested objects and inner classes

Each nested JSON object becomes a static inner class of its parent by default. This keeps the file count small and groups related classes together. You can refactor inner classes to top-level classes later if a class needs to be reused across multiple endpoints — most IDEs have a one-click refactor for this.

Frequently asked questions

Common questions about the JSON → Java tool.

Should I use Jackson or Gson annotations?
Jackson is the de facto standard in Spring Boot and most enterprise Java codebases, so pick it if you are unsure. Gson is lighter and easier to set up for small projects. The generated POJOs are structurally identical — only the annotations differ, and you can convert between them with a find-and-replace if you ever switch libraries.
How are property names mapped?
Java field names are derived from JSON keys using standard camelCase conversion. If a key contains characters that are not valid in a Java identifier, they are replaced with underscores. Jackson's @JsonProperty annotation is added to preserve the original JSON key, so the round-trip stays exact.
What types are used for numbers?
Integers become int (or Integer for nullable fields), large integers become long, and decimals become double. If you need precise decimal arithmetic (currency, financial data), replace double with BigDecimal after generation — doubles are not safe for money.
How are nested objects handled?
Each nested JSON object becomes a static inner class of its parent by default. You can configure the generator to emit every class as a top-level class instead, which is what most Java code generators do. Inner classes keep the file count small; top-level classes work better with package-by-feature layouts.
Does the generator support inheritance and generics?
Lintify generates plain POJOs without inheritance, because inferring a class hierarchy from a single sample is unreliable. If you need generics (for example, a generic PaginatedResponse<T>), generate the inner class first and then refactor it into a generic by hand — the generated code is a starting point, not a final design.

Related tools