JSON Conversion Guide:
CSV, XML, TOML, and When to Use Each

You're Probably Using JSON. But the Other Side Wants Something Else.

JSON is the default data format for modern web development. APIs speak JSON. Config files are JSON. Your frontend state is probably JSON-shaped even if you don't think about it that way. But eventually, you'll hit a situation where the other system — a database, a spreadsheet, a legacy SOAP service, a Rust build tool — expects something different. CSV. XML. TOML. YAML.

Each of these formats fills a different niche, and knowing when to reach for which one saves hours of fighting with data that's in the wrong shape. This guide walks through converting JSON to and from these formats, the tradeoffs of each, and the practical scenarios where each conversion makes sense.

JSON to CSV: When You Need a Spreadsheet

CSV is the universal format for tabular data. Every spreadsheet application, every database import tool, every data analysis platform — they all understand CSV. If you've got a JSON array of objects from an API and someone says "can you put this in Excel?", CSV is your answer.

The conversion is straightforward: each object in the array becomes a row, and the object keys become column headers. But real-world JSON often has complications that the naive converter misses.

Nested Objects

A flat JSON array like [{"name":"John","age":30}] converts cleanly. But what about [{"name":"John","address":{"city":"NYC","zip":"10001"}}]? The nested address object can't be a single CSV cell — at least not in a way that Excel will display meaningfully.

Approach 1: flatten the JSON first. Use the JSON Flatten tool to convert address.city into a top-level key. Then convert to CSV. You get columns like name, address.city, address.zip.

Approach 2: serialize the nested object as a JSON string in the CSV cell. Excel won't parse it, but your downstream code can.

Inconsistent Keys

When objects in your JSON array have different keys — some have phone, some don't — the CSV output should still work. The header row should include the union of all keys across all objects, and missing values become empty cells. The JSON to CSV and CSV to JSON converters handle this correctly.

Values with Commas and Quotes

CSV uses commas as delimiters and double quotes for escaping. A value like New York, NY needs to be wrapped in double quotes: "New York, NY". And a value that itself contains double quotes needs them doubled: "He said ""hello""". A good converter handles this automatically; a hand-rolled regex usually gets it wrong.

JSON to XML: When the Legacy System Calls

XML was the standard before JSON took over. It still runs large parts of the enterprise world — SOAP APIs, RSS feeds, sitemaps, office document formats, and government data exchanges. If you're integrating with a system built before 2010, there's a good chance it speaks XML.

The JSON ↔ XML converter handles the translation. JSON objects become XML elements, keys become tag names, and arrays produce repeated elements. But the conversion isn't lossless in either direction.

What XML Has That JSON Doesn't

XML supports attributes, comments, namespaces, processing instructions, and mixed content (text and elements interleaved). None of these have natural JSON equivalents. A JSON→XML→JSON round trip will lose XML attributes unless the converter explicitly preserves them (ours converts attributes to @attrname child elements).

What JSON Has That XML Doesn't

JSON has proper data types: numbers are numbers, booleans are booleans, null is null. XML treats everything as text. When converting XML to JSON, a value of 42 could be the number 42 or the string "42" — the converter has to guess based on context, and sometimes it guesses wrong.

When the Conversion Works Well

For data-oriented XML — configuration files, RSS feeds, sitemap XML, API responses — the conversion is clean and reliable. For document-oriented XML — XHTML, DocBook, anything with mixed content — expect to do manual cleanup after conversion.

JSON to TOML: Configuration Files Done Right

TOML (Tom's Obvious, Minimal Language) was designed for one purpose: configuration files. It's the standard format for Rust projects (Cargo.toml), Python packaging (pyproject.toml), and a growing number of other tools. It's cleaner than JSON for config because it supports comments, and less error-prone than YAML because it uses explicit syntax rather than meaningful indentation.

The JSON to TOML converter maps JSON objects to TOML tables. Top-level keys become key-value pairs; nested objects become [section] tables. The result is readable, commentable, and ready for use in any TOML-compatible tool.

Why migrate a config file from JSON to TOML?

• Comments. JSON doesn't support comments. TOML does. When your config file has 50 settings and you need to explain why each one has its value, comments matter.
• Readability. TOML's [section] syntax creates clear visual separation between groups of related settings. JSON's nested braces require careful bracket-matching.
• Explicit types. TOML has explicit date, time, and datetime types. JSON treats dates as strings and relies on the parser to interpret them correctly.

JSON to YAML: Human-Readable Config

YAML is the dominant format for DevOps — Docker Compose, Kubernetes manifests, Ansible playbooks, GitHub Actions. It's a superset of JSON, meaning any valid JSON is also valid YAML. But YAML adds features that make it better for human-written config files: comments, anchors and aliases for deduplication, and multi-line string support.

The JSON ↔ YAML converter handles both directions. JSON to YAML is straightforward — braces become indentation, quotes become optional. YAML to JSON requires more care, especially with YAML's type inference (the Norway problem: writing no as a country code gets interpreted as boolean false).

Choosing the Right Format: A Decision Framework

Scenario	Use	Why
REST API response	JSON	Universal support, native parsing in every language
Spreadsheet import	CSV	Direct import into Excel, Sheets, database tools
Enterprise integration	XML	SOAP services, government data, legacy systems
Application config	TOML or YAML	Comments, readability, industry convention
DevOps / CI/CD	YAML	Standard for Docker, Kubernetes, GitHub Actions
Rust project config	TOML	Cargo.toml is universal in the Rust ecosystem

The Conversion Toolchain

Here's a common workflow: you get JSON from an API, but you need it in three different formats. Flatten it first (for CSV compatibility), convert it to CSV for the data analyst, to XML for the legacy reporting system, and to TOML for the deployment config. All of these conversions happen locally in your browser with the tools linked below — no data leaves your machine.

For deeply nested JSON, flatten first, then convert. The flat representation is always easier to map to CSV, XML, or TOML than the nested original. Use the JSON Flatten tool as a pre-processing step before any format conversion.