Data Format Converter
Convert between JSON, YAML, TOML, INI and XML in any direction — with the places where a conversion cannot be faithful.
XML has no arrays, so an array of one vanishes into a value
JSON has a list type. XML does not — it has repeated elements, which is a different thing that looks the same in the common case. An array of three becomes three siblings and reads correctly. An array of one becomes one element, which is byte-for-byte what a plain value produces:
| JSON | XML |
|---|---|
{"tags":"a"} | <tags>a</tags> |
{"tags":["a"]} | <tags>a</tags> |
{"tags":["a","b","c"]} | <tags>a</tags> <tags>b</tags> <tags>c</tags> |
{"tags":[]} | (nothing) |
The first two rows are different JSON and identical XML. Nothing downstream can tell them apart, so anything reading that XML back has to guess — and it will guess wrong for every single-element list in the document. An empty array is worse: it produces nothing at all, so the key disappears entirely.
This is not a flaw in the converter — it is what the target format can express, and the array of three shows the mechanism working fine. Repetition is what carries list-ness in XML, and repetition of one is indistinguishable from not repeating. Schemas exist precisely to say "this element repeats"; without one, the shape is unrecoverable.
And every value arrives as a string
The same thing happens to types, and it is easier to overlook because the output looks perfectly fine:
| These two | Both give |
|---|---|
{"v":42} and {"v":"42"} | <v>42</v> |
{"v":true} and {"v":"true"} | <v>true</v> |
{"v":null} and {"v":"null"} | <v>null</v> |
Three more pairs that cannot be told apart afterwards. XML content is text: there is no number, no boolean and no null, and a reader has to be told what to expect. The values themselves do survive — 42 and 43 still differ — so it is precisely the type that is lost. That is the whole reason XML Schema exists and JSON mostly gets away without one.
Keys that are not valid XML names collide
JSON keys are arbitrary strings; XML element names are not. This converter checks each key and
substitutes item when it cannot be used, which keeps the output well-formed and
means several distinct keys can land on the same tag:
| JSON key | Becomes |
|---|---|
name | <name> |
first-name | <first-name> |
a.b | <a.b> |
first name | <item> |
2fa | <item> |
@id | <item> |
(empty string) | <item> |
Six realistic awkward keys collapse to 3 distinct tags, with
4 of them sharing a single <item>. Once that has
happened the original names are gone, so the conversion is one-way for any document whose
keys are not already identifiers.
The rule is more generous than people expect, though. Hyphens and dots are perfectly legal in
XML names, so first-name and a.b come through untouched. It is
spaces, leading digits and symbols that fail — which is a much shorter list than the
one most people carry in their heads.
How to use
- Paste your data and pick the target format.
- Review the output, especially comments and types.
- Quote anything ambiguous before converting to YAML.
- Check that nested structures survived.
Frequently asked questions
Which conversions lose information?
Any into a less expressive format. Comments are lost converting anything into JSON, since JSON has none. YAML anchors expand into duplicated content. XML attributes have no natural JSON equivalent and are usually mangled into ordinary keys, which is not reversible.
Why do my YAML values change type?
Because YAML infers types from unquoted text, and its rules are surprising. Version numbers lose trailing zeros because they are read as floats, and in older YAML versions the country code NO becomes false. Quoting anything that merely looks numeric or boolean prevents it.
What is TOML for?
Configuration, explicitly. It was designed to be unambiguous and obvious to read, avoiding YAML's type inference and indentation sensitivity while allowing comments that JSON cannot. It is used by Rust's Cargo and Python's packaging tooling among others.
Why is INI so limited?
Because it predates any of the others and was never really specified — different parsers disagree about nesting, comments, escaping and duplicate keys. It handles flat key-value sections well and anything structured badly, which is why it survives only in older software.
Which should I use for configuration?
TOML or YAML for anything a person edits, since both allow comments. JSON for machine-to-machine exchange, where its strictness is an advantage. Using JSON for hand-edited configuration is a common choice that people regret the first time they want to explain a setting.
Does my data get uploaded?
No. Parsing and conversion happen entirely in your browser, which matters given how often configuration files contain credentials.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.