MarkupSuite

XML vs JSON vs YAML vs TOML: How to Choose

4 min readUpdated September 2026
Rows of structured data on a screen

XML, JSON, YAML and TOML all solve the same basic problem — representing structured data as text — but each made different trade-offs about verbosity, typing and who the file is really written for. Reaching for the right one saves you from fighting a format that was designed for a different job. This guide walks through the strengths and the sharp edges of each, gives you a rule of thumb for choosing, and shows how to move data between them when you inherit the wrong one.

XML: powerful but verbose

XML is the oldest of the four. It wraps every value in a named opening and closing tag and supports attributes, namespaces, comments and rich schema validation through XSD and DTD. That richness makes it excellent for documents with mixed content and heavy metadata — XHTML, SVG and SOAP web services all build on it. The cost is verbosity: the same data is typically 20–40% larger than a JSON equivalent, and repeated closing tags make it noisier to read by eye.

XML also carries a self-describing header. A document usually opens with <?xml version="1.0" encoding="UTF-8"?>, which tells the parser how to decode the bytes before it reads a single tag — something JSON leaves to convention and out-of-band headers. Beyond that you get CDATA sections for embedding raw text that would otherwise need escaping, processing instructions, and entities. It is far from a museum piece: Maven's pom.xml, .NET .csproj project files, Android layouts, RSS 2.0 and Atom feeds, SOAP envelopes and the whole XSLT and XPath ecosystem are XML, and none of them are going anywhere.

JSON: the wire format

JSON strips a format down to pure data — objects, arrays and primitives, with no tags to close and no attributes to reason about. It parses natively in JavaScript and quickly everywhere else, which is why it dominates REST and GraphQL APIs. The trade-off is that standard JSON has no comments and no schema of its own, so it is a superb machine-to-machine format but an awkward one for files a human must hand-edit and annotate.

The specification is deliberately tiny. RFC 8259 defines six value types — object, array, string, number, true or false, and null — and that is the entire language. There are no trailing commas, keys must be double-quoted strings, and although the grammar allows numbers of any size, most parsers read them as IEEE 754 doubles, so an integer above 2^53 quietly loses precision. Tooling grew around the gaps rather than changing the format: JSON Schema for validation, JSON Lines for streaming one record per line, and the commented JSONC dialect that files like tsconfig.json rely on.

YAML: indentation and comments

YAML replaces punctuation with layout. Indentation marks nesting, a dash and a space marks a list item, and # starts a comment — which is why it took over CI pipelines, Kubernetes manifests, Ansible playbooks and docker-compose.yml. Since version 1.2 it is formally a superset of JSON, so any valid JSON document is also valid YAML, and features like anchors written &name, aliases written *name, and block scalars introduced with | or > let you factor out repetition and embed multi-line scripts without escaping. The price is that the same friendliness hides traps: tabs are illegal as indentation, and unquoted scalars are typed by guesswork.

TOML: explicit types in tables

TOML reached version 1.0.0 in January 2021 and takes the opposite stance: a value's type comes from its syntax, never from context. Bare numbers are numbers, quoted text is a string, dates follow RFC 3339, and integers must be handled as at least 64-bit signed values. Settings are grouped under bracketed table headers such as [dependencies], nested with dots as [tool.ruff.lint], and repeated with double brackets for arrays of tables. A duplicate key is a hard error rather than a silent overwrite. TOML is flatter than YAML by design, which makes Cargo.toml and pyproject.toml easy to skim but leaves deeply nested data feeling cramped.

A rule of thumb for choosing

A useful mental model maps each format to an audience. XML is for documents — anything where text and structure interleave and metadata matters. JSON is the wire format between systems, where speed and universal parser support beat readability. YAML is for deeply nested configuration that humans edit, especially where an ecosystem has already standardised on it. TOML is for flat-to-moderate settings files where you want no surprises. When two candidates look equally good, pick the one your language already reads without a dependency: Python 3.11 ships tomllib, Go and Rust have first-class JSON, and every browser parses XML.

Because all four describe the same kind of tree-shaped data, you can move between them. MarkupSuite converts XML, YAML and TOML to and from JSON, so you can author in whichever format suits the task and export to whatever the next tool expects — all in the browser, with nothing uploaded.

The takeaway

Reach for XML when documents, metadata and strict schemas matter, JSON for machine-to-machine data, YAML for nested config an ecosystem already expects, and TOML for settings that should read the same way to a person and a parser. MarkupSuite converts between all four through JSON.

Related tool
MarkupSuite · YAML

Open the tool and try it now