CSV vs JSON vs XML vs YAML: A Practical Guide to Data Formats

Guide · Updated July 2026

Four plain-text formats carry most of the structured data that moves between tools: CSV out of spreadsheets and databases, JSON out of APIs, YAML out of configuration files, and XML out of enterprise systems and feeds. Sooner or later every developer, analyst, and ops person needs to turn one into another. This guide explains what each format is actually good at, and — more usefully — the pitfalls that bite when you convert between them.

The four formats at a glance

CSV: the format that refuses to die

CSV is just rows of values separated by commas — which is precisely why it's everywhere. Excel, Google Sheets, every database and BI tool speaks it. But its simplicity hides sharp edges: there is no single CSV standard, so tools disagree about quoting, embedded commas and newlines, character encodings, and even the delimiter itself (much of Europe exports semicolon-separated "CSV"). And CSV is flat: it cannot represent a customer with a list of orders without inventing a convention. Everything is text; 00420 may silently become 420 the moment a spreadsheet touches it.

JSON: the lingua franca of APIs

JSON gives you objects, arrays, strings, numbers, booleans, and null — enough structure for most data, with parsers built into every language. Its strictness is a feature and an annoyance: one trailing comma and the file is invalid, and comments aren't allowed at all. JSON also comes in two working styles: minified (whitespace stripped, ideal for transmission and storage) and beautified (indented for human reading and code review). Converting between those two styles is one of the most common day-to-day developer chores — as is validating that a JSON blob is well-formed before blaming your code.

XML: verbose but rigorous

XML predates JSON and still runs vast amounts of infrastructure: RSS feeds, SOAP services, invoicing standards, Android resources. It supports things JSON genuinely lacks — attributes vs. elements, namespaces, schema validation — but that expressiveness is exactly why XML-to-JSON conversion is the trickiest of the bunch: should an attribute become a normal key? What happens to a repeated element when there's only one of it? Good converters apply consistent conventions, but round-tripping XML through JSON and back is rarely byte-identical. Know that going in, and treat converted output as a new artifact to verify rather than a perfect mirror.

YAML: config's favorite, with famous foot-guns

YAML is beloved for configuration because humans can read and comment it. It's also a superset of JSON in spirit: anything JSON expresses, YAML expresses more tersely. Its risks are legendary in ops circles: indentation errors silently change structure, and implicit typing turns unquoted values into surprises — the classic being country code NO parsed as boolean false (the "Norway problem"), or version 3.10 read as the number 3.1. Converting YAML to JSON is a time-honored debugging move precisely because it makes the parsed structure explicit and unambiguous.

The conversions you'll actually do, and their pitfalls

CSV → JSON

Usually rows-to-array-of-objects, with the header row supplying keys. Watch for: duplicated or blank headers, numbers that must stay strings (IDs, ZIP codes, phone numbers), and inconsistent row lengths. Validate the CSV first; a stray unquoted comma shifts every subsequent column.

JSON → CSV

Only cleanly possible when the JSON is an array of similarly-shaped flat objects. Nested structures must be flattened or serialized, and heterogeneous objects produce ragged columns. If your JSON is deeply nested, decide what the "rows" are before converting.

YAML ⇄ JSON

Structurally the most faithful pair, since their data models align. You lose comments going to JSON — sometimes that matters — and you gain explicitness. Converting a config to JSON to inspect what the parser actually sees is a genuinely useful trick.

XML ⇄ JSON

Expect convention decisions (attributes, repeated elements, mixed content) and verify the result against a sample. For feed-shaped XML this works well; for document-shaped XML with mixed text and markup, reconsider whether conversion is the right tool.

Why do this on a phone?

Because data doesn't wait for your laptop. A client texts you a CSV export and asks a question; a CI pipeline fails on a YAML file while you're commuting; an API dump needs to be readable now. And pasting company data into a random "free online JSON converter" website is exactly the kind of casual exfiltration security teams dread — that data goes to someone's server, subject to their logging (see our guide to online converter privacy).

How LocalConvert helps

LocalConvert includes a developer-grade data toolkit that runs entirely on your iPhone: CSV to JSON and JSON to CSV, XML ⇄ JSON, YAML ⇄ JSON, JSON minify and beautify, and CSV prettify and validate. No uploads, no internet required, no tracking — your data stays on your device. Free on the App Store.

Get LocalConvert free

Quick reference: choosing a format

• Sending tabular data to a non-developer? CSV — it opens in a spreadsheet.
• Feeding an API or a web app? JSON — minified for transport, beautified for humans.
• Writing configuration people will edit by hand? YAML — and quote anything that looks like it could be misread.
• Integrating with an enterprise or legacy system? XML — and let a schema validate it if one exists.

The bottom line

CSV, JSON, XML, and YAML each won their niche for real reasons, and none is going away. The practical skill isn't loyalty to one format — it's converting between them quickly, knowing the pitfalls (type loss in CSV, comment loss in YAML→JSON, convention ambiguity in XML), and doing it with tools that keep your data private while they work.