JSON, YAML, CSV, XML — Data Formats Explained

Whether you are configuring a web application, exchanging data between services, analyzing a spreadsheet export, or reading an API response, you will encounter data stored in structured text formats. The four most common are JSON, YAML, CSV, and XML.

Each format was designed with different goals in mind, and choosing the right one depends on your use case. This article explains what each format is, how it looks, when to use it, and how they compare.

JSON — JavaScript Object Notation

JSON has become the dominant data interchange format on the web. Despite its name, it is language-independent and used everywhere.

Syntax example:

{
  "name": "Alice Martin",
  "age": 34,
  "skills": ["Python", "SQL", "Docker"],
  "address": {
    "city": "Lyon",
    "country": "France"
  }
}

Key characteristics:

• Key-value pairs with a clean, readable syntax
• Supports strings, numbers, booleans, arrays, objects, and null
• No comments allowed in standard JSON
• Strict syntax — trailing commas and single quotes are errors

Common use cases: REST APIs, configuration files (package.json, tsconfig.json), NoSQL databases (MongoDB), data exchange between frontend and backend.

YAML — YAML Ain't Markup Language

YAML was designed to be the most human-readable data serialization format possible. It uses indentation instead of brackets and is particularly popular for configuration files.

Syntax example:

name: Alice Martin
age: 34
skills:
  - Python
  - SQL
  - Docker
address:
  city: Lyon
  country: France

Key characteristics:

• Indentation-based structure (no brackets or braces)
• Supports comments with #
• Supports all JSON data types plus more (dates, multiline strings)
• Whitespace-sensitive — incorrect indentation breaks the file

Common use cases: Docker Compose files, Kubernetes manifests, CI/CD pipelines (GitHub Actions, GitLab CI), Ansible playbooks, Hugo/Jekyll configuration.

YAML is a superset of JSON, meaning any valid JSON document is also valid YAML. However, YAML's flexibility can be a double-edged sword — its implicit type coercion (for example, yes being interpreted as a boolean true, or 3.10 becoming 3.1) has caused many subtle bugs.

CSV — Comma-Separated Values

CSV is the simplest structured data format. It stores tabular data as plain text, with each line being a row and values separated by commas (or sometimes semicolons, tabs, or other delimiters).

Syntax example:

name,age,city,country
Alice Martin,34,Lyon,France
Bob Dupont,28,Paris,France
Carol Smith,41,London,UK

Key characteristics:

• Extremely simple — just text with delimiters
• No data types — everything is a string
• No standard way to represent nested data
• No official universal standard (RFC 4180 exists but is not universally followed)
• File sizes are very small

Common use cases: Spreadsheet exports, database imports/exports, data analysis (pandas, R), simple data exchange, log files.

CSV's simplicity is its greatest strength and biggest limitation. It is perfect for flat, tabular data but cannot represent hierarchical structures. Edge cases (commas in values, multiline fields, encoding issues) make parsing more complex than it first appears.

XML — Extensible Markup Language

XML was the dominant data interchange format before JSON took over. It uses a tag-based syntax similar to HTML and supports complex features like schemas, namespaces, and transformations.

Syntax example:

<?xml version="1.0" encoding="UTF-8"?>
<person>
  <name>Alice Martin</name>
  <age>34</age>
  <skills>
    <skill>Python</skill>
    <skill>SQL</skill>
    <skill>Docker</skill>
  </skills>
  <address>
    <city>Lyon</city>
    <country>France</country>
  </address>
</person>

Key characteristics:

• Tag-based structure with opening and closing tags
• Supports attributes, namespaces, schemas (XSD), and transformations (XSLT)
• Supports comments
• Very verbose compared to other formats
• Extremely well-defined standard with strict validation

Common use cases: SOAP web services, enterprise integrations, document formats (DOCX, SVG, RSS), configuration files in Java/.NET ecosystems, government and financial data exchange.

XML is more verbose than JSON or YAML, but its schema validation capabilities make it invaluable in contexts where data integrity and formal contracts between systems are critical.

Side-by-Side Comparison

When to Use Which

• Choose JSON when building web APIs, storing configuration for JavaScript/TypeScript projects, or exchanging data between services. It is the default choice for most modern applications.
• Choose YAML when writing configuration files that humans will read and edit frequently. Its readability and comment support make it ideal for DevOps and infrastructure-as-code.
• Choose CSV when working with tabular data, importing/exporting from spreadsheets or databases, or when file size must be minimal. Avoid it for anything hierarchical.
• Choose XML when working with enterprise systems, SOAP APIs, or contexts requiring formal schema validation. It is also the right choice when you need document-oriented markup (like SVG or RSS).

Converting Between Formats

Converting between these formats is a common task. A few things to keep in mind:

• JSON to YAML (and vice versa) is usually lossless since YAML is a superset of JSON.
• CSV to JSON/YAML works well for flat data but requires decisions about structure for nested output.
• XML to JSON can lose information (attributes, namespaces, ordering) because JSON has no equivalent concepts.
• Any format to CSV works only if the data is flat or can be meaningfully flattened.

Going Further

ToolK.io provides free tools to convert between JSON, YAML, CSV, and XML, format and validate your data, and explore related tutorials for working with structured data in your projects.