Convert YAML, JSON, TOML, and XML

Configuration files come in four common shapes — JSON, YAML, TOML, and XML — and they rarely stay in the one you started with. A Kubernetes manifest arrives in YAML, a Rust project ships TOML, an API returns JSON, and a legacy system still speaks XML. Open the Data Format Converter to move between any of them without uploading a byte.

TL;DR

Pick a source and target, paste your data, convert, copy.

• Any-to-any — convert JSON, YAML, TOML, and XML into each other, all in your browser.
• Lossy warnings up front — when XML attributes or mixed text won’t round-trip exactly, the Warnings panel tells you before you trust the output.
• Copy or download — grab the result to the clipboard or save it with the target format’s extension, locally.

Why format conversion matters

These formats all describe the same thing — structured data with keys and values — but they were built for different goals, and ecosystems settle on whichever fits best. The friction shows up the moment data crosses a boundary: a CI pipeline reads YAML but the tool it invokes wants JSON; a Python project’s TOML config needs to be edited by a script that speaks JSON; an API returns JSON but the consuming service expects XML.

The honest truth is that the formats are not perfectly interchangeable (more on that in the limits section), but for the vast majority of config files — flat or shallowly nested settings, lists, and typed scalars — a clean conversion is exactly what you need. The tool’s job is to make that conversion fast, transparent, and to warn you when it isn’t lossless.

The four formats

Each format has a personality, and knowing when each is used helps you pick the right target:

• JSON — strict, ubiquitous, the default for APIs and package.json. Requires double-quoted strings, no trailing commas, no comments. Every parser agrees on it.
• YAML — human-friendly, driven by indentation. Powers Kubernetes, CI configs, and anything people hand-edit. Whitespace is significant, which is both its strength and its trap.
• TOML — typed, table-based, designed for config files. The choice for Rust’s Cargo.toml, Python’s pyproject.toml, and similar tooling. Clearer than INI, stricter than YAML.
• XML — verbose, attribute- and namespace-heavy. The legacy format that still surfaces in enterprise systems, SOAP APIs, and older document stores.

Step-by-step: convert between formats

The Data Format Converter runs entirely in your browser. Here is the workflow:

1. Pick the Source format and Target format. Two separate dropdowns select what you’re converting from and to. Use Swap to flip them instantly — handy when you just did JSON to YAML and now need the reverse.
2. Paste your input into the source area. If you’re unsure of the format, the tool can suggest one — a “Detected as” hint appears next to the source based on what you pasted.
3. Set the options. Three controls shape the output:
   • Indentation (0–8) — how many spaces to indent the result (ignored when minifying JSON).
   • Minify JSON — strips all whitespace when the target is JSON, for the smallest possible payload.
   • XML attribute prefix — the string prepended to keys that represent XML attributes (default @, max 4 characters).
4. Click Convert. The result appears in the output area, along with a Summary (format-to-format with the top-level item count) and a Warnings panel flagging anything lossy.
5. Copy or download. Use Copy result for the clipboard, or Download to save a file whose extension matches the target format. Use Clear to reset.

Lossy conversions and warnings

Some conversions cannot be perfect, and the tool is upfront about it. The Warnings panel lists each case so you know exactly where to look:

• XML attributes — attributes like <user id="7"> are stored under a prefixed key (@id by default). Converting to JSON or YAML preserves them, but converting back to XML relies on the prefix to distinguish attributes from child elements, which can be lossy in edge cases.
• Mixed XML text — when an element has both text and child elements, the text is stored under a #text key. That round-trips imperfectly because the original mixed structure isn’t expressible in JSON or YAML.
• XML names — element and attribute names are normalized to valid XML names, so unusual characters in keys get replaced.
• TOML nesting — deeply nested objects are flattened for TOML output and may need manual review.

When the Warnings panel is empty, the conversion round-trips cleanly. When it isn’t, read each warning and decide whether the affected parts matter to you. For flat config files you’ll usually see no warnings at all.

Limits and honesty

A few honest constraints, so you know exactly what you’re getting:

• YAML and TOML parsers are hand-rolled subsets. They handle the common cases — nested mappings, lists, scalars, quoted strings, numbers, booleans, null — but they are not full YAML or TOML spec libraries. Complex or edge-case structures (anchors and aliases in YAML, multiline strings, arrays of tables in TOML, dates and datetimes) may not parse or serialize exactly as a dedicated library would.
• JSON and XML are robust. JSON goes through JSON.parse, so any valid JSON parses exactly. XML uses a dedicated parser that handles attributes, nesting, and entities.
• Round-trips aren’t guaranteed. Because the lossy cases above (XML attributes, mixed text, TOML nesting) can’t always be expressed in the target format, converting A → B → A may not reproduce A exactly. Keep your original.

FAQ

Is the conversion lossless?

For flat and shallowly nested config files, yes — you’ll typically see an empty Warnings panel. For data that uses XML attributes, mixed XML text, or deep TOML nesting, the conversion can be lossy, and the Warnings panel flags each affected part. Treat warnings as your signal to review that section.

Can it convert YAML to JSON?

Yes. Set the Source format to YAML and the Target format to JSON (or use the detected suggestion), paste your YAML, and click Convert. The output is valid JSON, with indentation controlled by the Indentation option and optional minification.

Why does my XML round-trip differently?

Two reasons. XML attributes are mapped to prefixed keys (like @id), so distinguishing them from child elements on the way back depends on that prefix. And mixed content — an element with both text and children — is stored under #text, which doesn’t map cleanly back to mixed XML. The Warnings panel reports both cases. If round-trip fidelity matters, keep the XML original.

Does it support comments in JSON?

No. JSON has no comments in its spec, and the parser treats them as invalid input. If your input has comments, remove them before converting, or use a format that supports comments (YAML and TOML both do).