XML → TypeScript / Java / C# Generator

About this tool

This generator reads the structure of an XML document the same way a person would: it looks at which elements repeat (those become arrays), which ones are missing in some instances but not others (those become optional), which values look like numbers, booleans, or dates (those get typed accordingly), and which elements nest inside others (those become their own separate type, referenced from the parent). It's not doing text replacement on your XML — it builds a structural model first, then emits one of three target languages from that same model, which is why nested elements, arrays, and attributes all come out as properly separate, independently named types rather than one flat blob.

What becomes what

An attribute on an element becomes a field alongside that element's child-element fields. If an attribute and a child element happen to share the same name (an id attribute next to a <id> child, for instance), the attribute's generated field name gets an Attr suffix so the two don't collide — the underlying XML name used for serialization stays exactly as it was in your document either way.

Language-specific choices

TypeScript generates interface declarations. Dates come through as string (an ISO-8601 value, not a runtime Date object), since that's what actually round-trips through JSON/XML without a parsing step you'd have to add yourself.

Java generates plain POJO classes with private fields and generated getters/setters — no Lombok, no framework assumptions. Optional numeric and boolean fields use boxed wrapper types (Integer, Boolean) instead of primitives, since Java primitives can't represent "missing." Dates map to java.time.LocalDate / LocalDateTime.

C# generates classes with auto-implemented properties ({ get; set; }). Optional value types get a ? nullable suffix (int?, bool?, DateTime?) when the "Nullable optional fields" option is on.

Turning on Serialization attributes adds @XmlElement/@XmlAttribute/@XmlRootElement (Java, JAXB-style) or [XmlElement]/[XmlAttribute]/[XmlRoot] (C#, System.Xml.Serialization) so the generated class can serialize back to XML using each language's standard library, preserving the original element and attribute names even when a different naming convention is applied to the generated field names. TypeScript has no built-in equivalent, so this option has no effect there.

Everything runs locally in your browser using the built-in XML parser; nothing you paste or upload is sent to a server.

How to use it

1. 01

   Pick a target language

   TypeScript, Java, or C#. Switching languages regenerates instantly from the same parsed structure.

2. 02

   Set your options

   Naming convention, whether to preserve original XML names, comments, nullable optional fields, and serialization attributes.

3. 03

   Paste, upload, or drop your XML sample

   Use a representative sample — one with more than one instance of any repeating element gives more accurate optional/array detection.

4. 04

   Copy or download the generated code

   Copy to your clipboard, or download as a .ts, .java, or .cs file.

Example

<customer id="42">
  <name>Amy Chen</name>
  <email>amy@example.com</email>
  <tags>
    <tag>vip</tag>
    <tag>wholesale</tag>
  </tags>
</customer>

export interface Customer {
  id: number;
  name: string;
  email: string;
  tag: string[];
}

Common use cases

Limitations

• Types are inferred from the sample you paste, not from a schema. A field that's always numeric in your sample but could be text elsewhere in the real data won't be flagged — it'll just come out typed as a number.
• An element with genuinely mixed content (text alongside child elements) doesn't have a clean field-based representation in strongly typed classes; this tool models its child elements and attributes but doesn't separately capture the inline text.
• TypeScript's Date/date-time values are generated as string, not a parsed date object — you'll typically want to parse them yourself (e.g. new Date(x.releaseDate)) since XML date strings don't parse identically everywhere.
• Generated Java uses plain JAXB-style annotations, not framework-specific ones (Jackson XML, etc.); adapt the annotations if your project uses a different library.
• Very large or deeply irregular XML samples may produce a large number of generated types; review the output rather than assuming every field is exactly what you want long-term.

Best practices

• Use a sample that includes more than one instance of any element that can repeat — a single instance can't tell the generator that a field is actually optional or an array.
• Turn on "Preserve XML names" if you're going to hand-wire serialization yourself and want the field names to visually match the XML without relying on the serialization attributes.
• Review generated names for elements with unusual characters (hyphens, leading digits) — they're sanitized into valid identifiers, but double-check they still read naturally in your codebase.
• Treat the output as a strong starting point, not a final contract — especially for a document format that might evolve, where a real schema (see the XML ↔ XSD tool) is a more durable source of truth.

Frequently asked questions

Related tools