JSON ↔ YAML ↔ TOML ↔ XML Converter
Convert structured data between JSON, YAML, TOML, and XML
How to JSON ↔ YAML ↔ TOML ↔ XML Converter Online
Convert structured data between JSON, YAML, TOML, and XML.
- Pick the source format from the From dropdown (JSON, YAML, TOML, or XML).
- Pick the target format from the To dropdown.
- Paste your source document into the Input box — or click 'Use example' for a sample of the chosen From format.
- The output renders below in real time. There is no Convert button.
- If your input is malformed, the error message comes from the source-format parser with line/column info.
- Click Swap to reverse the direction — useful for round-trip sanity checks.
- Click Copy to put the converted output on your clipboard.
About JSON ↔ YAML ↔ TOML ↔ XML Converter
The four major configuration formats — JSON, YAML, TOML, XML — are each dominant in some part of the developer ecosystem and unfamiliar in others. JSON owns web APIs and JavaScript tooling. YAML owns Kubernetes, GitHub Actions, Ansible, CircleCI, and DevOps in general. TOML owns Rust (Cargo.toml), modern Python (pyproject.toml), and Hugo site configs. XML lives on in RSS, SOAP, Maven POMs, .NET configs, Android layouts, and every Microsoft Office document. If you work across more than one ecosystem, you eventually need to translate between them, and the translation is non-trivial because the formats have genuinely different type systems.
The converter pipeline is two stages. **Parse** the source into a generic in-memory JavaScript value (object, array, string, number, boolean, null). **Emit** that value into the target format using each format's idiomatic conventions. For JSON the parser is native; for YAML it is `js-yaml` (the same library GitHub Actions uses); for TOML it is `@iarna/toml` (the canonical JavaScript implementation); for XML it is the browser's built-in `DOMParser` plus a small custom walker. None of these involve a network round-trip — everything happens in your tab.
Where the formats actually disagree:
- **JSON** has six types (string, number, boolean, null, object, array). It is the lowest common denominator that everything else can downgrade to. - **YAML** adds dates, multi-line string variants, and aggressive type coercion. The famous "Norway problem" — `NO` parsing as boolean false — is gone in YAML 1.2 but the type-coercion surface is still wide. Unquoted `yes`, `on`, `null`, `~`, and pure numbers all coerce. - **TOML** has dates, times, an integer/float distinction, and tables-of-arrays as a first-class construct. It is the strictest of the four and explicitly tried to fix YAML's surprises. The price is more verbose syntax than YAML. - **XML** has no native types — everything is text — and forces a strict tree of named elements. The JSON↔XML mapping is the lossiest one because there is no canonical way to represent maps and arrays in XML. The converter uses a conservative convention: objects become element trees, arrays become repeating `<item>` tags, and the root is wrapped in `<root>` so XML's mandatory single-root rule is satisfied.
A few practical tips. **Round-trip sanity checks** are the fastest way to spot lossy conversions: convert JSON → YAML → JSON and compare to the original. If they differ, your source has type ambiguities (numbers-as-strings, booleans-as-strings) that the YAML stage normalized away. **For configs you will hand-edit, prefer YAML or TOML over JSON** — both support comments and multi-line strings. **For data passing between services, prefer JSON** — every language has a fast, correct, dependency-free parser, and the format has no type-coercion gotchas. **For SOAP/RSS/Office formats, you do not get a choice** — XML is the spec.
The converter handles edge cases that catch naive implementations. Empty input shows nothing rather than producing `null` or `{}`. Invalid syntax in the source format produces an error pointing at the line/column from the underlying parser. TOML's requirement that the root be a table is handled by wrapping bare values: pasting a JSON array converts to TOML as `value = [...]`. XML's parser-error mechanism (the special `<parsererror>` element `DOMParser` returns for malformed input) is surfaced as a clean error message.
Everything runs in your browser. The four parsers add up to ~80 KB compressed. Pasting configs that contain internal hostnames, environment-specific values, or vendor-API secrets is safe — the page makes zero network requests during conversion. You can verify in DevTools.
Related Tools
Frequently Asked Questions
Why do all four formats not map perfectly onto each other?
Because they have different type systems. JSON has six types (string, number, boolean, null, object, array). YAML adds dates, plus aggressive type coercion (yes/no/on/off as booleans). TOML adds dates, times, and an explicit integer/float distinction. XML has no native types — everything is text — and forces a tree of named elements rather than maps and arrays. The converter picks the most natural mapping at each step, but lossy conversions are possible. The reverse direction may not be byte-identical to the original.
How does the converter handle XML?
Two directions. **From XML**: child elements grouped by tag name become object keys; repeated sibling tags become arrays; text-only elements become strings (with conservative coercion of `true`/`false` and pure numbers). **To XML**: object keys become element names, arrays become repeating `<item>` elements, the root is wrapped in `<root>`. The result is canonical but not necessarily what you would hand-write — XML's structure is too rich to round-trip from JSON cleanly.
What is TOML good for?
Configuration files where humans edit and machines parse, and where you want minimal ambiguity. The TOML spec was designed by GitHub co-founder Tom Preston-Werner specifically because YAML had too many surprises. TOML's claim to fame is Rust's `Cargo.toml`, Python's `pyproject.toml`, and Hugo's site config. Compared to JSON, it has comments, multi-line strings, and a saner integer/float distinction. Compared to YAML, it has fewer footguns.
Why does my YAML round-trip change my numbers from `3.10` to `3.1`?
Because YAML parses unquoted `3.10` as the number 3.1 (trailing zeros are not significant for numbers). When the converter re-emits it, it shows the canonical numeric form. If you need `3.10` preserved as a string — a common case for version numbers — quote it in the source: `version: "3.10"`.
What happens to YAML anchors and aliases?
They get expanded inline. The dumper is configured with `noRefs: true`, which is the most predictable behavior for downstream consumers (Kubernetes, Terraform, CI systems all expand anchors on ingest). If you specifically need anchor preservation, use a round-tripping YAML library like Python's `ruamel.yaml` instead.
Can I convert just a slice of a larger document?
Yes — paste only the slice. The parser does not need to see a 'whole' file; it just needs valid syntax. For JSON paste a valid value (object, array, primitive). For YAML/TOML paste a valid document. For XML paste a single root element.
Is anything sent to a server?
No. All four parsers and emitters run in your browser. JSON uses native `JSON`, YAML uses `js-yaml`, TOML uses `@iarna/toml`, XML uses the browser's `DOMParser`. No network requests, no logging.