Generate Java classes from a YAML document — nested mappings as their own classes, sequences as List, sometimes-absent numeric fields boxed so absence reads as null, stringified non-string keys and Object slots all reported. Your input is never auto-saved: YAML is configuration, and configuration carries secrets. Free, no sign-up — runs locally in your browser.
Why generate Java classes from a YAML sample?
Java services are configured by YAML everywhere — Spring
Boot's application.yml, Kubernetes manifests a
controller reads back, CI definitions, test fixtures — and the
failure mode of a hand-written class is silence: a binder does
not complain about a key your class forgot; it leaves the
field at its default and the program runs on a wrong value.
Generating the classes from a real sample inverts that risk.
Every key in the sample gets a field with the inferred type,
nested mappings become their own classes, sequences of
mappings merge into one element class — and the judgement
calls (a key that only sometimes appears, a value that is
null, a key that had to be stringified) are written into the
notes instead of being buried in the output.
How to use this tool
- Paste the YAML, upload a file, or drop one on the panel. One document only — multi-document files are refused with an explanation.
- Name the root class.
Config is the default because that is what most YAML pasted here turns out to be. - Press Generate Java classes. The root class comes first, and
import java.util.List; appears only when a list is actually used. - Read the notes if any appear: boxed fields,
Object typings, stringified keys and anchor effects are all listed there. - Copy or download, and remember the input was never saved — if you clear the box, the YAML is gone from this tool entirely.
The mapping rules
Mappings become classes, with camelCase field
names and the original key kept in a trailing comment whenever
the spelling changed. Sequences become
List<…>, and a sequence of mappings yields
one merged element class. Scalars infer like
JSON: whole numbers long, decimals
double, true/false boolean, everything
else String — including dates, which this parser
hands over as strings, so a when: 2024-01-15 field
is a String unless you swap in a time type yourself. A field
missing from some items is boxed so absence can be null.
Nulls, mixed slots and empty sequences become
Object (or List<Object>) and
are always noted. Identical shapes share one class.
Worked example
Given this service configuration (the second endpoint has no retries):
service: api
replicas: 3
endpoints:
- path: /health
retries: 0
- path: /metrics
the converter emits:
import java.util.List;
public class Config {
public String service;
public long replicas;
public List<Endpoint> endpoints;
}
public class Endpoint {
public String path;
public Long retries;
}
The boxed Long on retries is the
second endpoint talking: the sample proves the key comes and
goes, so absence needs to be representable — as null.
Frequently asked questions
Plain classes, no annotations — how do I bind YAML to them?
The classes are field-for-field descriptions of your document, in the same style as this site's JSON to Java generator: public fields, camelCase names, the original key preserved in a comment whenever the spelling changed. Jackson's YAML module (jackson-dataformat-yaml) and SnakeYAML both bind by field name, so the comment spelling is what your binding configuration must match — or rename the field back and keep the shape. What the generator guarantees is the shape itself: every key in the sample has a field of the inferred type.
Why is this field a Long instead of a long?
Because the key is missing from some items of its sequence in your sample. A Java primitive cannot be null, so a sometimes-absent numeric or boolean field is boxed (Long, Double, Boolean) and absence reads as null — distinguishable from a real zero, which matters when zero means something. Fields present in every item keep the primitive. A sometimes-absent string or class field needs no boxing: the reference type already has null.
My YAML has several documents separated by ---. What happens?
The converter refuses, and says how many documents it found. Each document would need its own root class, and quietly generating the first (or merging them) would produce classes that misdescribe your file. Split the documents and convert each one, or name the root per document — that is a modelling decision, so the tool leaves it to you.
I use anchors, aliases and merge keys. Do they survive?
They are resolved before generation: an aliased mapping is seen as the full mapping it points at, and a merge key's entries appear as the fields they contribute, so the generated classes describe the values, not the anchor syntax. If two keys alias mappings with the same shape, they share one class, like any identical shapes. What is lost is the sharing itself — the class cannot say 'these two fields are the same object'. If your program depends on that identity rather than the values, no class generator can express it.
My keys aren't strings — YAML allows that. What happens to them?
Java field names and the binding both work from strings, so a numeric or boolean YAML key is treated as its string spelling (42 becomes "42") and the notes call out every key it happens to. One subtlety: YAML also distinguishes the keys 42 and "42"; a Java class cannot, so a document using both would collapse them — the sample would show only one field, and the notes are where to check if that matters to you.
Why isn't my input auto-saved like on other tools?
Because YAML is usually configuration, and configuration files carry secrets — API keys, tokens, internal hostnames, database passwords. This converter keeps no draft of your input or your root class name, in your browser or anywhere else: paste, convert, done. Refresh the page and it is gone — that is deliberate, and it is the same rule on every YAML tool on this site.
Dev