XML to TOON Converter

About Structure Converter

Converts between JSON, XML, YAML, TOML, TOON, INI, .env, Java .properties, HCL and CSV in any direction. Each conversion runs through one plain-value model — the source is parsed into it, the target is written from it — so every possible pair needs one reader and one writer per format rather than a mapping for each combination.

Two of those are flatter than the rest and the conversion says so rather than pretending otherwise. INI nests only as far as dotted section names go, so a list of objects has no spelling and is refused by name rather than written as something that will not read back. A .env file cannot nest at all — the environment is a flat map of string to string — so writing one flattens a tree into the PARENT_CHILD names that twelve-factor configuration actually uses, which is a flattening rather than a round trip: reading the result back gives the flat names, because nothing in the file records that DATABASE_HOST was once database.host.

Java .properties sits between the two. Its dotted keys are read as a path, so server.port=8080 becomes { server: { port } } and servers[0]=a the first entry of a list, the way Spring reads them; writing one flattens a tree back into those dotted and indexed keys. Every value in a properties file is a string, as Properties.getProperty returns it, so port=08 stays the two characters it was written as.

The formats do not carry the same things, and the result says so. CSV has no types and no nesting; XML has attributes and comments that JSON has nowhere to put; YAML has comments that are rebuilt away. TOML has dates and a real distinction between 1 and 1.0, neither of which survives a JSON value. Expect a faithful conversion of the data, not of the document.

HashiCorp's HCL — Terraform, Packer, Nomad, Vault — is read the way Terraform's own JSON syntax spells it: resource "aws_instance" "web" { … } nests as resource.aws_instance.web, and an expression such as var.ami_id or length(var.zones) is carried as the string "${var.ami_id}" and written back bare. Whether an object is a block or a map attribute is something a plain value cannot record, so writing HCL from JSON or YAML makes the well-known block types (resource, variable, module, lifecycle and the rest) blocks and everything else key = { … } attributes, which is also what a .tfvars file needs.

Where it helps

• Any of the text formats to any other, without chaining two tools together.
• Wrapped exports still convert to rows: the converter finds the array a document is really about.
• One value model means XML attributes, YAML scalars and JSON types behave consistently whichever direction you go.
• Sorting keys on the way out gives a canonical document, and for CSV a stable column order.
• Runs in the browser, so a customer export never leaves your machine.

Limits

• CSV carries no types, so everything read from it arrives as a string and needs casting afterwards.
• Writing CSV flattens nesting into dotted columns and writes arrays as JSON text, because a cell holds one scalar.
• XML attributes become @name keys and comments are dropped, since the other formats have nowhere to keep them.
• YAML output is rebuilt from the data, so comments and anchors in the source do not survive the trip.

Frequently asked questions

How does it decide which array becomes the CSV rows?

It looks for the single array in the document, unwrapping a wrapper object to find it. A document with no array at all becomes one row. If several arrays sit at the same level, extract the one you want first.

What happens to nested fields when I convert to CSV?

They become dotted columns — customer.name, customer.city. Arrays have no column of their own, so they are written as JSON text in the cell.

Why is every value from my CSV a string?

Because CSV has no types. Quoting decisions in the file are about escaping, not about whether something is a number, so nothing can be inferred safely — a postcode with a leading zero would lose it.

Can I convert a format to itself?

No — pick two different formats. To reformat a document, use the Structure Formatter; to compact one, the Structure Minifier.

Related tools

• Structure Formatter — Pretty-print JSON, XML, YAML, TOML, TOON or HCL with a chosen indent
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• Structure Minifier — Strip formatting from JSON, XML, YAML, TOML or TOON
• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back
• Code Generator — Turn a JSON, YAML, XML or other document into TypeScript, Go, C#, Python, Rust and more

More Structured Formats tools

• Structure Converter — Convert between JSON, XML, YAML, TOML, TOON, HCL and CSV
• String Escaper — Escape a JSON, XML, YAML, TOML or TOON document for embedding, or read one back
• Structure Formatter — Pretty-print JSON, XML, YAML, TOML, TOON or HCL with a chosen indent
• Structure Validator — Check JSON, XML, YAML, TOML, TOON or HCL and report structural problems
• Tree Viewer — Explore JSON, XML, YAML, TOML, TOON or HCL as a collapsible tree
• Code Generator — Turn a JSON, YAML, XML or other document into TypeScript, Go, C#, Python, Rust and more
• Schema Generator — Write a JSON Schema, XSD, Avro schema or .proto from a document you already have
• Schema Validator — Check a document against a JSON Schema, .proto, Avro schema, XSD or RELAX NG
• Table Viewer — Show the records in a JSON, XML, YAML, TOML or TOON document as a table
• Structure Compare — Diff two JSON, XML, YAML, TOML, TOON or HCL documents by path
• Structure Repair — Fix broken JSON, YAML, XML, TOML, TOON, INI, .env, .properties and HCL, listing every repair
• Structure Minifier — Strip formatting from JSON, XML, YAML, TOML or TOON
• Path Finder — Select nodes with JSONPath or XPath
• Protobuf & Avro Decoder — Read protobuf wire bytes and Avro container files without their schema
• Expression Evaluator — Reduce a JSONPath or XPath match to a single answer