JSON to POJO Converter

Convert JSON to Java POJO classes instantly. Generate Java model classes from JSON data for Java and Spring Boot development.

Upload a JSON or TXT file (max 5MB)

JSON Input

Java POJO Output

How to Use:

Paste your JSON content in the left textarea or upload a JSON file
Customize conversion options (class name, package, annotations, etc.)
Click "Convert to POJO" to generate your Java classes
Copy the Java code or download it as .java files
Use the generated classes in your Java/Spring Boot project

Generated Features:

Properly typed Java class fields with correct data types
Getters and setters for all fields
Constructors (with/without arguments)
toString, equals, and hashCode methods (optional)
Lombok annotations support (@Data, @Getter, @Setter, @Builder)
Jackson annotations (@JsonProperty) for JSON serialization
Gson annotations (@SerializedName) for Gson serialization
Nested class generation for complex objects
List and array type handling

Important: The Output Isn't One Compilable File

When your JSON has nested objects, this converter generates a separate Java class per nested object, then joins all of them together with blank lines into one block of text — and the Download button saves that entire block into a single .java file named after your root class. The catch: every one of those classes gets its own package ...; declaration and its own repeated import block, because each class is generated independently with the full header. Java only allows one package statement per file, and (in the standard convention) one public top-level class per file matching the filename — so pasting this multi-class output directly into a single file and compiling it will fail. Before using the output, split it into one .java file per class (the file starts fresh at each package line), name each file after its class, and keep only one package/import block per file.

A Checkbox Trap: Lombok Needs "Getters/Setters" Checked Too

Checking "Use Lombok Annotations" suppresses all of this tool's manually-written constructors, getters/setters, toString, and equals/hashCode — the assumption being that Lombok's own annotations will generate them instead at compile time. But the @Data annotation (the one that actually makes Lombok generate getters, setters, toString, equals, and hashCode) is only added to the class when the separate "Generate Getters/Setters" checkbox is also checked. If you check "Use Lombok" but leave "Generate Getters/Setters" unchecked, you get a class with private fields and no methods at all — no manual code (suppressed because Lombok is on) and no @Data (because that specific checkbox controls whether it's added). Always keep "Generate Getters/Setters" checked whenever "Use Lombok" is checked, unless you're deliberately building a fields-only class.

Type Inference Runs on One Sample Value — Know the Edge Cases

• Nested class names come from the field name, not its path: two different nested objects that happen to share a field name (say, "billing": {"address": {...}} and "shipping": {"address": {...}}) both generate a class literally called Address — a naming collision you'll need to resolve by hand across the split files.
• Integer vs Double depends on how the parsed number looks, not how you wrote it: JSON's 19.0 parses in JavaScript to the plain number 19, and Number.isInteger(19) is true — so a price field sampled as 19.0 is typed Integer, not Double. Use a genuinely fractional sample value (like 19.99) if the real field can hold decimals.
• List element type comes from the first array element only: a mixed-type array, or one where element zero isn't representative, produces a List<T> generic that's wrong for the other elements — there's no per-element type checking across the whole array.
• A field that's null in your sample becomes the bare Object type: unlike a real value, a null sample gives the converter nothing to infer from, so you'll want to manually change that field's type after generation if you know what it should actually be (String, Integer, a nested class, etc).

One Thing It Gets Right: Boolean Getters

Worth calling out since it's easy to get wrong by hand: this converter correctly generates isActive() rather than getActive() for boolean/Boolean-typed fields, matching standard JavaBeans convention that many hand-written POJOs get wrong or inconsistent. If you're using Jackson or Gson, this matters because both libraries' default reflection-based (de)serialization expects that is-prefixed pattern for boolean accessors.

Frequently Asked Questions

I pasted the output into one .java file and it won't compile — why?

Nested JSON objects generate multiple classes, each with its own package declaration and import block, all concatenated into one text output. Java doesn't allow multiple package statements in a single file, so you need to split the output into one file per class (named to match its class name) before compiling.

I checked "Use Lombok" but got a class with no methods at all — what happened?

Lombok's @Data annotation, which is what actually triggers Lombok to generate getters/setters/toString/equals, is only added when the "Generate Getters/Setters" checkbox is also checked. Enabling Lombok on its own, with that checkbox off, suppresses the manual code without adding the Lombok annotation that would replace it. Check both together.

Why is a decimal-looking price field typed `Integer`?

JavaScript's JSON parser doesn't distinguish 19.0 from 19, so a whole-number sample always infers Integer. Use a genuinely fractional example value in your sample JSON (like 19.99) to get Double instead, then adjust by hand if needed.

Two generated classes have the same name — what do I do?

Rename one manually after conversion (and in the split file's filename). This happens because nested class names are derived purely from the field name, without regard to where in the JSON tree that field appears, so two differently-nested objects with the same field name collide.

Should I use Jackson or Gson annotations?

Use Jackson's @JsonProperty if your project already depends on Jackson (the default in Spring Boot). Use Gson's @SerializedName if you're on Android or already using Google's Gson library. Both let the field's JSON key differ from its Java field name, which matters if your JSON uses snake_case keys that you want converted to camelCase fields.