MarkupSuite

Converting Between XML, YAML, TOML and JSON

4 min readUpdated September 2026
A network of connected nodes

Sooner or later every developer needs to turn a YAML file into JSON, or a TOML config into something another tool understands. The mechanics are easy, but conversions are rarely perfectly lossless, and knowing where information leaks out saves you from subtle bugs that surface weeks later. The key insight is that JSON serves as the common hub every other format converts through — which is both why conversion is simple and why it drops things.

Why JSON is the hub

XML, YAML and TOML all describe the same underlying thing: a tree of maps, lists and scalar values. JSON is the leanest way to write that tree, so it makes a natural interchange point. Rather than build a direct converter for every pair of formats, tools convert any format to JSON and JSON back to any format — turning a messy many-to-many problem into a simple hub and spokes. That is exactly how MarkupSuite works: each tab converts its format to and from JSON.

The hub also explains why a conversion is a projection rather than a translation. Each spoke expresses things the hub cannot — XML attributes and namespaces, YAML comments and anchors, TOML's typed dates — so the trip through JSON keeps the data and drops the decoration. That is usually what you want when the destination is another program. It is not what you want when the destination is the same file, edited by a person: a documented YAML config round-tripped through JSON comes back correct and completely undocumented.

What gets lost

Conversions lose whatever the target format cannot express. Comments vanish the moment you convert to JSON, since JSON has none — so never treat a JSON round-trip as a safe way to reformat a documented config. XML attributes have no JSON equivalent and are usually folded into keys with a prefix like @_, while XML namespaces and processing instructions disappear entirely. Going the other way, key ordering may change, and a YAML value that was implicitly a number stays a number once it lands in JSON.

Shape shifts too. JSON objects are unordered by definition, so a converter is free to re-sort keys, and a TOML file rebuilt from JSON may group its tables differently from the one you started with. YAML anchors and merge keys are expanded on the way in, so ten job definitions that shared a single anchor come back as ten full copies — correct, but four times the file and no longer edited in one place. Multi-document YAML files, several Kubernetes resources separated by three dashes, have no JSON equivalent at all and must be split or wrapped in an array first.

XML's special cases

XML is the awkward spoke, because its model is richer than a map of values. Attributes are usually folded into keys with a marker prefix, and an element's own text becomes a synthetic key such as #text when the element also carries attributes. Repeated elements are the real trap: from a single <item> a converter cannot tell whether the schema allows many, so a list of one often becomes a single object rather than an array of one — and code that loops over it breaks the day the input has two. Mixed content, comments and processing instructions have nowhere to go, and CDATA sections arrive as ordinary strings, because JSON escapes rather than delimits.

Types that do not line up

Scalars are where silent damage happens. TOML dates are real date-time values, but JSON has no date type, so they arrive as strings and will not turn back into dates unless the target parses them again. TOML has no null either, so a JSON null has no legal destination and is usually dropped along with its key. Integers above 2^53 lose precision passing through a JavaScript JSON parser, even though TOML guarantees 64-bit. And in XML everything is text until a schema says otherwise, so 007 and the string "007" are indistinguishable without the XSD — the converter has to guess, and sometimes it guesses wrong.

A safe conversion workflow

Work in three steps. First, format and validate the source file so you start from something known to be correct. Second, convert it to JSON and read the result carefully — this is where you catch a boolean that should have been a string, an attribute that landed in an unexpected place, or a single-element list that collapsed into an object. Third, convert the JSON to your target format and eyeball the output before committing it, paying attention to comments you now need to restore. The middle JSON view is your inspection window; never skip it for anything important.

MarkupSuite puts that workflow on one screen: format and validate on the source tab, convert to JSON to inspect the tree, then convert the JSON into YAML or TOML. Every step runs in the browser with nothing uploaded, so you can safely do it with a config that holds internal hostnames or credentials.

The takeaway

Every format converts through JSON as a common hub, and each hop drops what the target cannot express — comments, attributes, namespaces, dates, nulls. Use the JSON view in MarkupSuite as an inspection step before converting onward, and restore comments by hand.

Related tool
MarkupSuite · YAML

Open the tool and try it now