XML to Java Converter
Scaffold Java classes from an XML document — get a class for each element with fields ready to fill in, instead of typing the boilerplate by hand.
A head start on your data classes
If you're mapping an XML document into Java, the tedious part is typing out a class for each element and a field for each child. This converter writes that skeleton for you. It reads your XML and emits a set of nested Java classes whose names mirror your element names and whose fields mirror the children — so you start from a structure instead of a blank file.
The flow is two steps. xml2js parses the XML into an object, then a generator walks that object: each nested element produces a public class (named after the element) plus a field referencing it, while each leaf element becomes a public String field. The output is plain, readable Java you copy into your project and refine.
Set expectations correctly: this is a scaffold, not a finished, compile-ready model. Every leaf is typed as String because XML carries no type information, and there are no getters, setters or annotations — those are deliberate decisions you make per project. The tool saves the keystrokes; you supply the polish.
Scaffolding Java from XML
- 1
Paste the XML
Add your XML to the input pane or upload a file. The sample loads a small document to demonstrate the output.
- 2
Read the classes
A set of nested Java classes appears in the output pane, one per element, with a field for each child.
- 3
Refine in your IDE
Copy it into your project, then adjust field types, add getters and setters, and apply any JAXB or Jackson annotations you need.
- 4
Copy or download
Copy the Java or save it as a .java file to start from.
What the scaffold buys you
Skip the typing
A class per element and a field per child is generated instantly — no manually transcribing the XML shape into Java.
Mirrors your structure
Class and field names follow your element names, so the model lines up with the document you're mapping.
A clear starting point
Begin from a real skeleton you refine, rather than staring at an empty file deciding where to start.
Runs locally
Your XML is parsed and the classes are generated in the browser, so proprietary schemas stay private.
From elements to classes
The XML on the left scaffolds into the nested Java classes on the right.
<book>
<title>Dune</title>
<author>
<name>Frank Herbert</name>
</author>
</book>public class Root {
public book book;
public class book {
public String title;
public author author;
public class author {
public String name;
}
}
}Know what you're getting before you compile
The generated code is intentionally minimal: nested classes named after elements, with public fields. Every leaf field is a String, because XML doesn't tell us whether <year>1965</year> is a number or text. That means the scaffold won't compile into a fully-typed model untouched — you'll change some String fields to int, boolean or domain types, and likely add encapsulation. Treat the output as the boring 80% done for you, leaving the meaningful 20% of decisions to you.
Turning the scaffold into production code
- Replace
Stringfields with real types where the data is numeric, boolean or a date. - Add getters and setters (or switch to a record / Lombok) to match your codebase's conventions.
- Layer on binding annotations —
@XmlElementfor JAXB or Jackson's XML annotations — if you'll deserialize XML directly. - Rename classes to satisfy Java naming conventions where element names don't (for example hyphenated tags).
Frequently asked questions
Not quite — it's a scaffold. Every leaf field is typed as String and there are no getters, setters or annotations. You copy it in and refine it: adjust types, add encapsulation, and apply binding annotations as your project needs.
XML has no type information, so the converter can't tell whether 1965 is a number or text. It plays safe and types every leaf as String, leaving you to change fields to int, boolean or a date type where appropriate.
No. Those are project-specific choices, so the scaffold leaves them out. Add getters/setters (or use a record or Lombok) and annotations like @XmlElement once the code is in your IDE.
Each nested element becomes its own class named after the element, and the parent gets a field referencing it. So a name inside an author inside a book produces nested author and book classes.
No. xml2js parses the XML and the classes are generated entirely in your browser, so internal schemas and data models never leave your machine.
Tags with hyphens or other characters that Java doesn't allow in identifiers will need renaming after generation. The scaffold mirrors your element names verbatim, so adjust them to follow Java conventions.
Need another tool?
Browse the full toolbox or dig into the blog for the engineering behind it.