JSON vs CSV vs XML vs YAML — When to Use Which (with Examples)

Pick the wrong data format and you'll spend the rest of the project converting back and forth, fighting with parsers, or — worse — locked into a format your team hates. The four big ones are JSON, CSV, XML, and YAML. Each one is a great fit for a specific job and a terrible fit for the others.

This is the short, opinionated guide to when to use which, with real examples and the gotchas that bite you on the second project.

At a glance

JSON — the universal default

JSON is the data format the modern web is built on. Every major language has a built-in parser. Every REST API speaks it. It is compact, fast to parse, and natural for JavaScript developers because the syntax is just JavaScript object literal syntax (with stricter rules).

{
  "id": 42,
  "name": "Ada Lovelace",
  "skills": ["math", "logic"],
  "born": 1815
}

Use JSON when:

• You're building or consuming an HTTP/REST API.
• You need to represent nested data — objects within objects within arrays.
• You're storing structured data that a program will read more often than a human.
• You want every modern language to handle it natively.

JSON gotchas:

• No comments. Strict JSON has no comment syntax. If you need them, use JSON5 or YAML for config.
• No trailing commas. Allowed in JavaScript, illegal in JSON. The JSON formatter catches these instantly.
• Strings must use double quotes. Single quotes are not valid.
• Special numbers don't work. NaN, Infinity, undefined — none of these are valid. Use null or a string.

CSV — the spreadsheet standard

CSV (comma-separated values) is the oldest of the four and still the right choice for tabular data that someone might open in Excel, Google Sheets or Numbers. Every record on a new line, every column separated by a comma. That's it.

id,name,skill,born
42,Ada Lovelace,math,1815
43,Grace Hopper,compiler,1906

Use CSV when:

• You're exporting data for non-developers to open in Excel.
• You're doing bulk imports into databases or marketing tools.
• Your data is genuinely flat — rows of records with the same fields.
• You want a format that works in every spreadsheet app ever made.

CSV gotchas — pretty much everyone trips on these:

• Commas inside values. A value like Lovelace, Ada breaks naive parsers. Wrap in quotes: "Lovelace, Ada".
• Quotes inside values. Escape them by doubling: "She said ""hi""".
• No nesting. CSV is fundamentally 2D. To store a list per row, you either delimit with another character (pipe, semicolon) or accept the data is the wrong shape for CSV.
• Locale-specific separators. European Excel often uses semicolons. If your CSV opens with all columns in one, that's why.
• Date formatting. Always export dates as ISO 8601 (2026-05-20). Excel will reformat them locally on import — your problem now.

XML — the enterprise veteran

XML predates JSON by about a decade and still powers a lot of enterprise software, RSS feeds, SOAP APIs and document formats like Microsoft Office files. It's verbose but expressive — and unlike JSON it has a real schema language (XSD) and namespaces.

<?xml version="1.0"?>
<user>
  <id>42</id>
  <name>Ada Lovelace</name>
  <skills>
    <skill>math</skill>
    <skill>logic</skill>
  </skills>
</user>

Use XML when:

• You're integrating with legacy enterprise systems (SOAP, healthcare HL7, financial FpML).
• You need rigorous schema validation across organisations.
• You're working with documents that have mixed text + markup (HTML is essentially XML, so are RSS feeds and .docx files).

XML gotchas:

• Verbosity. XML is 2-3x bigger than equivalent JSON. Matters at scale.
• Attributes vs child elements. Two ways to represent the same thing leads to bikeshedding. Pick one convention and stick to it.
• XXE attacks. XML parsers can be tricked into reading server files via external entity references. Always disable DTD processing for untrusted input.
• Whitespace handling. XML preserves whitespace by default which is rarely what you want.

YAML — the configuration language

YAML ("YAML Ain't Markup Language") trades JSON's brackets for indentation. It's designed for humans to read and edit by hand — which is exactly why it's now the default for CI configs, Kubernetes manifests, Docker Compose files, Ansible playbooks and GitHub Actions.

user:
  id: 42
  name: Ada Lovelace
  skills:
    - math
    - logic
  born: 1815

Use YAML when:

• Developers will edit the file by hand — configs, CI pipelines, infrastructure.
• The file is small enough to read top to bottom in one go.
• You want comments. YAML supports them with #; JSON doesn't.

YAML gotchas — the famous ones:

• Indentation matters. Use spaces, never tabs. One wrong indent and the whole structure changes.
• The Norway problem. NO as a string gets parsed as the boolean false. Quote country codes and any short uppercase string.
• Strings vs numbers. version: 1.10 becomes the float 1.1, dropping the trailing zero. Quote version numbers.
• Anchors and references. Powerful but rarely worth it for hand-written configs.

The decision tree

1. Is the data tabular and going to a non-developer? CSV.
2. Is it a config a developer will edit by hand? YAML.
3. Is it for an HTTP API or web application? JSON.
4. Are you integrating with a SOAP API, legacy enterprise system, or document format? XML.
5. Anything else? Default to JSON.

Converting between them safely

The 12 possible conversions all have gotchas. Common ones:

• JSON → CSV: nested objects must be flattened or stringified. CSV cannot represent arrays directly.
• CSV → JSON: every value comes back as a string. You may need to coerce numbers and booleans yourself.
• XML → JSON: attributes vs child elements ambiguity — pick a convention (e.g. attributes get a $ prefix).
• YAML → JSON: YAML supports more types (dates, anchors). Some get downgraded. Always parse and re-serialise to verify.

Save yourself the parsing pain — the file converter handles all 12 paths with proper quoting, escaping and nesting. Paste in, pick the target format, copy out.

The honest answer

In 2026, if you're building anything new on the web, default to JSON until you have a specific reason not to. Use YAML for configs that humans write. Use CSV for spreadsheet output. Only reach for XML when something outside your control demands it.

The mistake isn't picking the "wrong" format — it's using one format for every job. Each of these was designed for a different problem, and that's exactly when they shine.