JSON to Java Converter
Generate Java POJO classes from a JSON sample — fields, getters/setters and nested classes, ready for Jackson or Gson.
The POJO boilerplate, generated
Java's verbosity is nowhere more painful than in DTOs: a 30-field API response means a hundred lines of fields, getters and setters before you write a single line of logic. Paste the JSON sample instead — every object becomes a class, every array a List<T>, numeric types are chosen sensibly (long vs double), and nested structures become properly named nested classes.
Ready for Jackson and Gson
The generated classes are plain POJOs with a default constructor shape that Jackson's ObjectMapper.readValue() and Gson's fromJson() both consume directly. Where a JSON key isn't a legal Java identifier, keep the library's annotation handy (@JsonProperty("…") / @SerializedName("…")) — the class skeleton stays the generated one, you add the annotation on the odd field out.
Maven-era pragmatics
Records instead of classes? For Java 17+ codebases, converting the generated POJOs to records is a five-minute mechanical edit — the type inference (what is long, what is Optional-ish, how deep the nesting goes) was the actual work. If your build fails on generation output, first check the JSON itself in the JSON Validator; broken samples are the usual culprit, not the generator.
Frequently asked questions
Does the output work with Jackson and Gson?
Yes — the classes are plain POJOs, exactly what both libraries bind to by default. Only JSON keys that are not valid Java identifiers (or that collide after renaming) need a @JsonProperty/@SerializedName annotation on top.
Why long and double instead of int and float?
JSON numbers carry no size information, so the generator picks the safe wider types: integers become long, decimals double. Narrow them manually where you know the domain (e.g. quantity as int).
Can it generate Java records?
The output is classic POJO classes for maximum compatibility. For Java 17+ record conversion is mechanical: the field list and types — the inferred part — transfer 1:1.
How are nested objects handled?
Each distinct object shape becomes its own class (Customer, Line, …) referenced from the parent — matching how you would hand-write a DTO hierarchy, just without typing it out.