JSON to Java
Convert JSON into Java model classes — plain POJOs, Lombok @Data, or records. Runs in your browser — nothing is sent to a server.
With @JsonProperty off, the annotation is still emitted for any field whose Java name cannot match its JSON key (snake_case keys, reserved words, keys with punctuation) — without it those fields would silently deserialize to null.
How to Use JSON to Java
- Paste your JSON into the left panel, or click a sample to load one. Conversion runs automatically about half a second after you stop typing.
- Set the root class name — it defaults to
Root. Nested classes are named after their JSON key. - Pick a style. POJO emits private fields plus getters and setters. Lombok @Data emits just the fields and lets Lombok generate the accessors. Java record emits an immutable record (Java 16+).
- Choose how nested types are emitted. Separate top-level classes are easy to split into one file each; static inner classes keep everything in a single file.
- Only the root class is declared
publicin separate mode, so the whole output compiles as one.javafile. Addpublicback when you move each class into its own file. - Copy the result with the Copy button on the output panel.
What Is a POJO, and Why Generate One From JSON?
A POJO — Plain Old Java Object — is an ordinary Java class with fields and accessors and no dependency on a framework base class or interface. When you consume a REST API from Java, you almost never work with the raw JSON text. Instead you hand the response body to a mapper such as Jackson or Gson along with a target class, and the mapper populates an instance of that class field by field. That class is your model, and writing it by hand for a fifty-field payload is tedious and easy to get wrong.
The payoff is type safety. Once the response is a real object, the compiler checks every access, your IDE autocompletes field names, refactoring tools can rename a property across the whole project, and a typo becomes a compile error instead of a null at runtime. Generating the model from a real sample response also means the shape you code against is the shape the server actually sends, not the shape the documentation claims.
This tool reads one concrete JSON sample and infers a schema from it. That is a useful approximation, not a
contract. Feed it the richest sample you have — one where optional fields are present and arrays are non-empty —
and always review the result. Fields the sample happened to omit will not appear, and a field that is
null in your sample cannot reveal its real type.
Type Mapping and Naming Rules
JSON has six value types and Java has many more, so every generator has to make choices. Here are the ones this tool makes:
- String maps to
String, boolean toboolean. - Whole numbers become
int, orlongwhen the sampled value falls outside the 32-bit signed range. Numbers with a fractional part becomedouble. - null becomes
Object, because a null value carries no type information at all. This is the one mapping you should almost always replace by hand. - Arrays become
List<T>. An empty array becomesList<Object>since there is no element to inspect. Mixed-type arrays also fall back toList<Object>. - Nested objects get their own class, named by PascalCasing the key. An array of objects produces
List<Singular>, where the element class is generated once from the union of every element in the array — so a field present on only the second item is not lost. - Two nested objects with identical shapes share a single generated class rather than producing duplicates.
- Keys become camelCase field names. A key that is a Java keyword such as
classorpublicgets a trailing underscore; a key starting with a digit gets a leading underscore; punctuation is dropped. Whenever the Java name stops matching the JSON key, a@JsonPropertyis emitted so the mapping still works.
POJO vs Lombok vs Record — Which Should You Pick?
Plain POJO is the safest default. It has no build-time dependencies, works on every Java
version, and every tool in the ecosystem understands it. The cost is verbosity: two accessors per field, so a
twenty-field model runs to a couple of hundred lines. Note that the getter for a
boolean field is
isActive(), not
getActive() — that is the JavaBeans convention
Jackson relies on to discover properties.
Lombok @Data collapses all of that into one annotation. At compile time Lombok generates the
getters, setters, equals,
hashCode and
toString for you, so the source stays a readable
list of fields. It needs the Lombok dependency and annotation processing enabled in your build and IDE. Because
@Data produces setters, the resulting object is
mutable — reach for @Value if you want it frozen.
Java records (Java 16 and later) are the most concise option and are immutable by construction:
the components are final, and accessors are named after the component rather than prefixed with
get. Jackson has supported record deserialization
since 2.12, and annotating the record components with
@JsonProperty — as this tool does — is the reliable
way to bind them without depending on compiled parameter names. Records are ideal for read-only API responses and
DTOs; they are a poor fit when a framework insists on a no-argument constructor, as older JPA entities do.
Specifications
- Accepts
- Text — type or paste
- Gives you
- copy to clipboard
- Where it runs
- Your browser — the file is never uploaded
- Sign-up
- None
- Cost
- Free, with no usage limits
FAQ
Why do snake_case JSON keys need @JsonProperty?
Java field names conventionally use camelCase, but JSON APIs very often use snake_case. Jackson matches properties by name, so a field named createdAt will not bind to a JSON key named created_at and you get a silent null. Adding @JsonProperty("created_at") tells Jackson exactly which key feeds that field. The alternative is to configure a global naming strategy such as PropertyNamingStrategies.SNAKE_CASE on the ObjectMapper, which removes the need for per-field annotations when every key follows the same convention.
What happens to JSON keys that are Java reserved words?
You cannot name a Java field class, public, int or new — they are keywords, and the code would not compile. This tool appends a trailing underscore, so the key "class" becomes the field class_ and the key "public" becomes public_. Keys that begin with a digit get a leading underscore instead, since identifiers cannot start with a number. In every one of these cases the Java name no longer equals the JSON key, so a @JsonProperty annotation is emitted alongside it and the mapping still round-trips correctly.
Why does a null value become Object?
A JSON null tells you a value is absent but says nothing about what type it would have been. String, number, object and array are all consistent with null in a single sample, so there is no sound inference to make and Object is the honest fallback. Treat it as a prompt to check the API docs or find a sample where the field is populated, then replace Object with the real type — and prefer a boxed type such as Integer or Boolean over a primitive for any field that can legitimately be null.
Should I use int or long for numeric IDs?
The tool picks int when the sampled value fits in a signed 32-bit integer and long when it does not. That is a decision based on one sample, so it can be wrong in either direction: an ID that happens to be small today may exceed 2,147,483,647 next year. Snowflake-style IDs, epoch-millisecond timestamps and monetary values in minor units all overflow int quickly, so widen those to long by hand. For currency amounts prefer BigDecimal over double, since binary floating point cannot represent decimal fractions exactly.
Can I use the generated classes with Gson instead of Jackson?
Yes, with one change. The class shapes are identical — Gson also populates fields from a JSON document — but the annotation differs: Gson uses @SerializedName("created_at") where Jackson uses @JsonProperty("created_at"). Turn the Jackson option off, swap the remaining annotations, and update the import. Gson reads private fields reflectively and does not need getters, so the Lombok style pairs well with it. Records need Gson 2.10 or newer.
Is my JSON uploaded anywhere?
No. The parsing and code generation both run in JavaScript inside your browser, so nothing is transmitted to a server and nothing is stored. That makes it safe to paste a real API response that contains internal identifiers or customer data. You can confirm this by opening your browser network tab while converting, or by disconnecting from the network — the tool keeps working offline once the page has loaded.