JSON vs YAML vs TOML vs XML vs CSV: Complete Data Format Comparison for Developers

Every developer works with data formats daily. Whether you are building a REST API, writing a Kubernetes manifest, configuring a build tool, exporting database records, or defining SVG graphics, you are choosing a format to represent structured data. The five most common formats in 2026 are JSON, YAML, TOML, XML, and CSV, and each one makes fundamentally different tradeoffs between simplicity, expressiveness, readability, and ecosystem support.

This guide provides an exhaustive, side-by-side comparison of all five formats. We cover syntax, data types, strengths, weaknesses, real-world use cases, conversion strategies, and a practical decision framework. By the end, you will know exactly when to reach for each format and why.

1. Overview: The Five Data Formats at a Glance

Before diving deep into each format, here is a high-level summary of what each one is and where it came from.

JSON (JavaScript Object Notation) was formalized by Douglas Crockford in the early 2000s, based on a subset of JavaScript syntax. It quickly became the universal language of web APIs and data interchange. Defined in RFC 8259, JSON is supported natively by every modern programming language.

YAML (YAML Ain't Markup Language) was first released in 2001 and is currently at version 1.2.2. It was designed to be human-readable and is technically a superset of JSON. YAML became the de facto standard for infrastructure configuration, powering Kubernetes, Docker Compose, GitHub Actions, and Ansible.

TOML (Tom's Obvious, Minimal Language) was created by Tom Preston-Werner (co-founder of GitHub) in 2013, with version 1.0.0 released in January 2021. It was designed specifically for configuration files, not general data serialization. TOML powers Cargo.toml (Rust), pyproject.toml (Python), and many modern tool configurations.

XML (eXtensible Markup Language) was published as a W3C recommendation in 1998. It is the oldest format on this list and was the dominant data interchange format before JSON. XML remains essential in enterprise systems, document markup (HTML, SVG, XHTML), SOAP web services, and anywhere strict schema validation is required.

CSV (Comma-Separated Values) predates all of the above, with origins in the 1970s. It was formalized as RFC 4180 in 2005. CSV is the simplest possible data format: plain text rows with comma-delimited fields. It is the lingua franca of tabular data exchange, powering spreadsheet imports, database exports, and data science workflows.

2. JSON: The Universal Data Interchange Format

Syntax

JSON has six data types: strings (double-quoted), numbers, booleans (true/false), null, arrays, and objects. Every key must be a double-quoted string. There are no comments, no trailing commas, and no date type.

{
  "app_name": "my-web-app",
  "version": "2.1.0",
  "debug": false,
  "port": 8080,
  "database": {
    "host": "localhost",
    "port": 5432,
    "credentials": null
  },
  "allowed_origins": [
    "https://example.com",
    "https://app.example.com"
  ]
}

Pros

• Universal support. Every language, platform, and tool understands JSON. It is the default for REST APIs, GraphQL responses, browser storage, and inter-service communication.
• Unambiguous parsing. The specification is short and precise. Two conformant parsers always produce the same result from the same input.
• No implicit type coercion. A value is exactly the type it looks like. There are no surprises.
• Rich ecosystem. JSON Schema for validation, jq for command-line querying, and SchemaStore.org for hundreds of format definitions.
• Hierarchical structure. Objects and arrays can nest to arbitrary depth, supporting complex data models.

Cons

• No comments. The single biggest limitation for configuration files. You cannot explain settings or leave notes.
• Verbose syntax. Every key must be quoted. Delimiters are required everywhere. Large config files become walls of braces and quotes.
• No trailing commas. Adding or removing the last item requires modifying two lines, creating noisy diffs.
• No multiline strings. Long strings must use \n escape sequences.
• No date type. Dates are stored as strings, requiring manual parsing and format conventions.

Use Cases

• REST and GraphQL API responses and requests
• Package manifests: package.json, tsconfig.json, composer.json
• Browser localStorage and sessionStorage
• NoSQL databases (MongoDB, CouchDB, DynamoDB)
• Inter-service communication in microservices architectures
• Configuration files where the file is machine-generated (package-lock.json)

3. YAML: The Human-Friendly Configuration Heavyweight

Syntax

YAML uses indentation (spaces only, never tabs) to represent nesting. Colons separate keys from values, dashes denote list items. It supports strings, numbers, booleans, null, dates, arrays, mappings, anchors, aliases, and multi-document files.

# Application configuration
app_name: my-web-app
version: "2.1.0"  # Quote to prevent float interpretation
debug: false

server:
  host: 0.0.0.0
  port: 8080
  workers: 4
  tls:
    enabled: true
    cert: /etc/ssl/cert.pem

allowed_origins:
  - https://example.com
  - https://app.example.com

# Anchors and references for DRY configuration
defaults: &default_timeouts
  connect_timeout: 30
  read_timeout: 60

production:
  <<: *default_timeouts
  read_timeout: 120  # Override just this value

# Multi-line strings
description: |
  This is a block scalar.
  Line breaks are preserved exactly.

summary: >
  This is a folded scalar.
  Line breaks become spaces,
  creating a single paragraph.

Pros

• Highly readable. Indentation-based nesting looks clean even at 5+ levels deep, making YAML excellent for complex infrastructure definitions.
• Comments. Full-line and inline comments with #, essential for documenting configuration.
• Anchors and aliases. The & and * operators let you define a value once and reference it elsewhere, reducing repetition in large configs.
• Multi-document support. A single YAML file can contain multiple documents separated by ---.
• Multiline strings. Block scalars (| for literal, > for folded) handle long text gracefully.
• Superset of JSON. Every valid JSON document is also valid YAML.

Cons

• Implicit type coercion (the "Norway Problem"). In YAML 1.1, NO parses as boolean false. Country codes, version numbers, and other values are silently reinterpreted. yes, no, on, off are all booleans. 1.0 becomes a float. 0777 becomes an octal integer.
• Indentation sensitivity. A single misplaced space can change the document structure without causing a parse error.
• Massive specification. Over 80 pages. Most developers understand only a subset, leading to unexpected behavior with unknown features.
• Security concerns. Some YAML parsers support arbitrary object instantiation, leading to remote code execution vulnerabilities. Always use yaml.safe_load().
• Tabs are forbidden. YAML requires spaces for indentation. A single tab character causes a parse error.

Use Cases

• Kubernetes manifests and Helm charts
• CI/CD pipelines: GitHub Actions, GitLab CI, CircleCI, Travis CI
• Ansible playbooks and roles
• Docker Compose files
• OpenAPI / Swagger specifications
• Any deeply nested configuration where readability matters

4. TOML: The Configuration Specialist

Syntax

TOML uses explicit key = value pairs organized into [sections] (tables). All types are unambiguous: strings are always quoted, booleans are only true/false, and dates follow RFC 3339.

# Application configuration
app_name = "my-web-app"
version = "2.1.0"
debug = false

[server]
host = "0.0.0.0"
port = 8080
workers = 4

[server.tls]
enabled = true
cert = "/etc/ssl/cert.pem"
key = "/etc/ssl/key.pem"

[database]
host = "localhost"
port = 5432
name = "myapp_production"
created = 2026-01-15T10:30:00Z

allowed_origins = [
    "https://example.com",
    "https://app.example.com",
]

# Array of tables (list of objects)
[[routes]]
path = "/api"
handler = "api_handler"

[[routes]]
path = "/health"
handler = "health_check"

# Multi-line strings
description = """
This is a multi-line basic string.
It supports escape sequences like \n and \t."""

regex_pattern = '\d+\.\d+'  # Literal string, no escaping

Pros

• No implicit type coercion. Every value has an explicit, unambiguous type. "yes" is always a string, true is always a boolean, 1.0 is always a float.
• Comments. First-class comment support with #.
• Native date/time types. RFC 3339 dates are built into the language.
• Short specification. A developer can read the entire TOML spec in one sitting (~3,000 words).
• Not indentation-sensitive. Structure comes from section headers and key names, eliminating invisible whitespace bugs.
• Duplicate key rejection. Redefining a key is a parse error, preventing silent data loss.
• Trailing commas in arrays. Cleaner diffs when adding items.

Cons

• Verbose deep nesting. At 3+ levels, dotted table headers like [a.b.c.d] become unwieldy compared to YAML's natural indentation.
• No null type. You cannot express "this value is explicitly absent." You must omit the key entirely.
• No anchors or references. No way to reuse values without external tooling.
• Smaller ecosystem. Fewer tools and parsers than JSON or YAML in some languages, though growing rapidly.
• Not suitable for data interchange. Designed for config files, not API responses or serialization between services.

Use Cases

• Cargo.toml (Rust package manager)
• pyproject.toml (Python project configuration, PEP 517/518/621)
• hugo.toml (Hugo static site generator)
• netlify.toml (Netlify deployment config)
• Application configuration files with moderate nesting
• Tool-specific settings ([tool.ruff], [tool.pytest] in pyproject.toml)

For a deep dive into TOML syntax and real-world usage, see our Complete Guide to TOML Configuration Files.

5. XML: The Enterprise Document Format

Syntax

XML uses nested tags with opening and closing elements. It supports attributes on elements, namespaces for avoiding name collisions, processing instructions, CDATA sections for raw content, and mixed content (text interspersed with elements). XML is both a data format and a document markup language.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Application configuration -->
<config xmlns="http://example.com/config"
        xmlns:sec="http://example.com/security">

    <app-name>my-web-app</app-name>
    <version>2.1.0</version>
    <debug>false</debug>

    <server host="0.0.0.0" port="8080">
        <workers>4</workers>
        <tls enabled="true">
            <cert>/etc/ssl/cert.pem</cert>
            <key>/etc/ssl/key.pem</key>
        </tls>
    </server>

    <database>
        <host>localhost</host>
        <port>5432</port>
        <name>myapp_production</name>
        <sec:credentials encrypted="true">
            <sec:username>admin</sec:username>
        </sec:credentials>
    </database>

    <allowed-origins>
        <origin>https://example.com</origin>
        <origin>https://app.example.com</origin>
    </allowed-origins>

    <description><![CDATA[
        This is raw content. Special characters like < > & " are
        preserved without escaping inside CDATA sections.
    ]]></description>

</config>

Pros

• Powerful schema validation. XSD (XML Schema Definition) and DTD (Document Type Definition) provide formal, machine-enforceable validation. You can define required elements, data types, cardinality constraints, and complex content models.
• Namespaces. Multiple vocabularies can coexist in the same document without name collisions, critical for enterprise integration.
• Attributes and elements. The dual data model (attributes for metadata, elements for content) allows rich, nuanced document structures.
• Mixed content. XML can contain text interspersed with markup elements, making it the foundation for document formats (HTML, DocBook, XHTML).
• Comments. Full comment support with <!-- --> syntax.
• Transformation ecosystem. XSLT for transforming XML documents, XPath/XQuery for querying, XSLT-FO for generating PDF output.
• Self-describing. Element names provide context about the data they contain.
• CDATA sections. Embed raw text without escaping special characters.

Cons

• Extremely verbose. Every element requires both an opening and closing tag. A simple key-value pair like "port": 8080 in JSON becomes <port>8080</port> in XML. File sizes are significantly larger.
• No native data types. Everything is text. Numbers, booleans, and dates must be parsed from strings, and schema is needed to define types.
• Complex parsing. XML parsers (DOM, SAX, StAX) are heavier and slower than JSON or TOML parsers.
• No native arrays. Lists are represented by repeating elements, which is less intuitive than JSON arrays or YAML sequences.
• Namespace complexity. While powerful, namespaces add significant verbosity and complexity to both documents and parsers.
• Falling out of favor. New projects rarely choose XML unless the ecosystem mandates it. JSON has replaced XML for most web APIs.

Use Cases

• Enterprise web services (SOAP, WSDL, WS-*)
• Document markup: HTML, XHTML, SVG, MathML, DocBook
• Java/Android configuration (pom.xml, web.xml, AndroidManifest.xml)
• .NET configuration (app.config, web.config, .csproj)
• RSS and Atom feeds
• Office documents (OOXML: .docx, .xlsx, .pptx are ZIP archives of XML files)
• Data interchange where strict schema validation is required
• Publishing and typesetting (DITA, JATS)

6. CSV: The Simplest Tabular Data Format

Syntax

CSV files are plain text where each line represents a row and values within each row are separated by commas. An optional header row names the columns. Fields containing commas, quotes, or line breaks must be enclosed in double quotes. Double quotes within fields are escaped by doubling them.

name,age,city,description
Alice,30,New York,"Software engineer"
Bob,25,"San Francisco, CA","Full-stack developer"
Charlie,35,Austin,"He said ""hello"" to everyone"
"Diana Prince",28,London,"Multi-line
description works when quoted"

Pros

• Universal compatibility. Readable by virtually every programming language, database, spreadsheet application, and text editor.
• Extreme simplicity. No markup, no syntax to learn beyond "commas separate values, quotes escape special characters."
• Smallest file size. Zero overhead for markup or metadata. A CSV file is just the data.
• Fastest parsing. Simple parsing logic means CSV files process faster than any other format for equivalent data.
• Human-readable. Open in any text editor and immediately understand the data.
• Spreadsheet native. Excel, Google Sheets, and LibreOffice Calc open CSV files directly, making it the bridge between databases and spreadsheets.

Cons

• Flat structure only. CSV cannot represent nested or hierarchical data. It is strictly tabular: rows and columns.
• No native data types. Everything is text. Numbers, dates, and booleans are all strings that must be parsed by the consuming application.
• No metadata. No way to specify encoding, data types, or column constraints within the file itself.
• No comments. There is no comment syntax in the CSV specification.
• Encoding ambiguity. No standard way to declare character encoding. UTF-8, Windows-1252, and ISO-8859-1 files are indistinguishable without detection.
• Delimiter confusion. European locales use semicolons instead of commas (because commas are decimal separators), leading to interoperability issues.
• Quoting edge cases. Naive parsers that use split(",") break on quoted fields, and proper parsing is more complex than it appears.

Use Cases

• Spreadsheet data exchange (Excel, Google Sheets, LibreOffice)
• Database imports and exports
• Data science and machine learning datasets
• Financial data and transaction records
• Log files and analytics data
• Contact lists, email imports, CRM data
• Any flat tabular data where simplicity and universal compatibility matter most

For a comprehensive deep dive, read our Complete Guide to Working with CSV Files.

7. Side-by-Side Comparison Table

The following comprehensive table compares all five formats across the dimensions that matter most for developers.

8. When to Use Which Format: A Decision Guide

Choosing a data format is not about which is "best." It is about which one fits your specific constraints. Use this decision framework to choose deliberately rather than by default.

Use JSON when:

• Building REST APIs or web services that exchange data between client and server
• The file is primarily machine-generated and machine-consumed (API responses, lock files, serialized state)
• You need maximum interoperability across languages and platforms
• Working with NoSQL databases (MongoDB, CouchDB, DynamoDB) that store JSON natively
• The toolchain mandates it (TypeScript, ESLint, Prettier, package.json)
• You need hierarchical data with type preservation (strings, numbers, booleans, null)

Use YAML when:

• The configuration has deep nesting (4+ levels) and human readability matters
• You need anchors and references to reduce repetition in large configs
• The ecosystem mandates it (Kubernetes, Docker Compose, GitHub Actions, Ansible, GitLab CI)
• You need multi-document support in a single file
• You are writing infrastructure-as-code definitions

Use TOML when:

• The configuration has moderate nesting (1-3 levels)
• Humans will frequently read and edit the file
• You want explicit typing without implicit coercion surprises
• The file is an application config, package manifest, or tool settings
• The ecosystem supports it (Rust, Python, Hugo, Netlify)

Use XML when:

• You need strict schema validation (XSD/DTD) with complex content models
• Working with enterprise systems (SOAP, WSDL, WS-* standards)
• The data is a document with mixed content (text interspersed with markup)
• You need namespaces for combining multiple vocabularies
• The ecosystem mandates it (Java enterprise, .NET, Android, Maven, Gradle)
• Working with SVG graphics, RSS feeds, or XHTML documents

Use CSV when:

• The data is flat and tabular (rows and columns, no nesting)
• You need universal compatibility with spreadsheets, databases, and every programming language
• Working with data science, analytics, or machine learning datasets
• Performing database exports/imports or data migration
• File size matters and you need the smallest possible representation
• Non-technical users need to view or edit the data in Excel

Quick Decision Matrix

9. Converting Between Formats

Real-world projects often require converting data between formats. Here are practical approaches for the most common conversions.

JSON to YAML and YAML to JSON

# Using yq (the YAML equivalent of jq)
# JSON to YAML
yq -P config.json > config.yaml

# YAML to JSON
yq -o=json config.yaml > config.json

# Using Python
python3 -c "
import json, yaml, sys
data = json.load(open('config.json'))
yaml.dump(data, sys.stdout, default_flow_style=False)
"

# Reverse direction
python3 -c "
import json, yaml, sys
data = yaml.safe_load(open('config.yaml'))
json.dump(data, sys.stdout, indent=2)
"

JSON to TOML and TOML to JSON

# Using Python (requires tomli-w: pip install tomli-w)
# JSON to TOML
python3 -c "
import json, tomli_w, sys
data = json.load(open('config.json'))
tomli_w.dump(data, sys.stdout.buffer)
"

# TOML to JSON (Python 3.11+)
python3 -c "
import tomllib, json, sys
with open('config.toml', 'rb') as f:
    data = tomllib.load(f)
json.dump(data, sys.stdout, indent=2, default=str)
"

# Format the TOML output
taplo format config.toml

XML to JSON and JSON to XML

# Using Python xmltodict
pip install xmltodict

# XML to JSON
python3 -c "
import xmltodict, json, sys
with open('data.xml') as f:
    data = xmltodict.parse(f.read())
json.dump(data, sys.stdout, indent=2)
"

# JSON to XML
python3 -c "
import xmltodict, json
with open('data.json') as f:
    data = json.load(f)
print(xmltodict.unparse(data, pretty=True))
"

# Using xq (part of yq for XML)
xq . data.xml  # XML to JSON
yq -o=xml . data.json  # JSON to XML

CSV to JSON and JSON to CSV

# Using Python pandas
import pandas as pd
import json

# CSV to JSON
df = pd.read_csv('data.csv')
records = df.to_dict(orient='records')
with open('data.json', 'w') as f:
    json.dump(records, f, indent=2)

# JSON to CSV (flat objects only)
with open('data.json') as f:
    data = json.load(f)
df = pd.DataFrame(data)
df.to_csv('output.csv', index=False)

# Using csvkit (command line)
csvjson data.csv > data.json
in2csv data.json > data.csv

# Using Miller (mlr)
mlr --c2j cat data.csv > data.json
mlr --j2c cat data.json > data.csv

Important Caveats for Format Conversion

• Comments are lost. JSON and CSV have no comments. Converting from YAML, TOML, or XML to these formats discards all comments.
• Hierarchical to flat loses information. Converting JSON, YAML, or XML to CSV requires flattening nested structures, which may lose structural relationships.
• XML attributes are tricky. XML's dual model (attributes + elements) does not map cleanly to JSON's single model (keys + values). Conventions vary: some tools prefix attribute names with @.
• YAML type coercion. When converting YAML to JSON, values that YAML silently converted to booleans or floats may not match expectations.
• TOML dates. TOML's native date type has no equivalent in JSON (stored as ISO 8601 strings) or CSV (plain text).
• CSV encoding. Always specify UTF-8 encoding when converting to or from CSV to avoid character corruption.

10. The Same Data in All Five Formats

To illustrate the differences concretely, here is the same simple dataset represented in all five formats. This is a list of two servers with their hostname, port, and enabled status.

JSON

{
  "servers": [
    {
      "hostname": "alpha.example.com",
      "port": 8080,
      "enabled": true
    },
    {
      "hostname": "beta.example.com",
      "port": 9090,
      "enabled": false
    }
  ]
}

YAML

# Server list
servers:
  - hostname: alpha.example.com
    port: 8080
    enabled: true
  - hostname: beta.example.com
    port: 9090
    enabled: false

TOML

# Server list
[[servers]]
hostname = "alpha.example.com"
port = 8080
enabled = true

[[servers]]
hostname = "beta.example.com"
port = 9090
enabled = false

XML

<?xml version="1.0" encoding="UTF-8"?>
<!-- Server list -->
<servers>
    <server>
        <hostname>alpha.example.com</hostname>
        <port>8080</port>
        <enabled>true</enabled>
    </server>
    <server>
        <hostname>beta.example.com</hostname>
        <port>9090</port>
        <enabled>false</enabled>
    </server>
</servers>

CSV

hostname,port,enabled
alpha.example.com,8080,true
beta.example.com,9090,false

The contrast is striking. CSV is the most compact (3 lines). YAML is the most concise for structured data (7 lines). JSON is balanced (13 lines). TOML is explicit (10 lines). XML is the most verbose (12 lines plus the declaration). Each format brings different overhead, and that overhead matters at scale.

11. Format Evolution and Future Trends

The data format landscape continues to evolve. Here are the notable trends shaping the future of each format.

JSON remains the undisputed standard for web APIs and is unlikely to be displaced. JSON5 (with comments and trailing commas) and JSONC (JSON with Comments, used by VS Code) address some usability issues for configuration, though neither has achieved widespread adoption as a wire format. The rise of JSON Schema has strengthened JSON's position in API design and validation.

YAML 1.2 fixed many of the implicit type coercion issues from 1.1, but adoption is slow. Many popular parsers (including Python's PyYAML) still default to 1.1 behavior. The YAML ecosystem is consolidating around stricter usage patterns, with linters like yamllint becoming standard in CI pipelines.

TOML is on a strong growth trajectory. Python's inclusion of tomllib in the standard library (3.11+) was a major milestone. More tools are adopting TOML as their configuration format, and the ecosystem is maturing rapidly with taplo providing formatting, linting, and schema validation.

XML is stable but declining for new projects. It remains dominant in enterprise systems, publishing, and document markup (SVG, XHTML), but new greenfield projects rarely choose XML unless the ecosystem mandates it. The XML ecosystem (XSLT, XPath, XQuery, XSD) is mature and well-understood, ensuring XML's longevity in its established niches.

CSV is irreplaceable for tabular data exchange. It will continue to serve as the lowest common denominator for data transfer between spreadsheets, databases, and data science tools. The trend toward Parquet and other columnar formats for large datasets has not displaced CSV for everyday use.

Frequently Asked Questions

Conclusion

There is no single "best" data format. JSON, YAML, TOML, XML, and CSV each solve different problems, and the right choice depends on your specific context, constraints, and audience.

JSON is the right choice when you need universal interoperability and the data is primarily consumed by machines. Its strict syntax and ubiquitous parser support make it the default for APIs, data interchange, and toolchain configuration.

YAML is the right choice when you need expressive power for deeply nested, complex configurations that humans will read and edit. The infrastructure world chose YAML for good reasons, despite its complexity and implicit typing pitfalls.

TOML is the right choice when humans are the primary audience and the configuration has moderate complexity. Its explicit typing, comment support, and short specification make it the safest choice for application settings and package manifests.

XML is the right choice when you need formal schema validation, namespaces, mixed content, or when your enterprise ecosystem mandates it. It remains irreplaceable for document markup and standards-heavy enterprise integration.

CSV is the right choice when your data is tabular and you need maximum simplicity, compatibility, and the smallest possible file size. It is the universal bridge between databases, spreadsheets, and data analysis tools.

In practice, most developers use all five formats across different projects. The key insight is not to pick a favorite, but to understand the strengths and limitations of each so you can choose the right tool for the job.