DEV Community

Mikasa Ackerman
Mikasa Ackerman

Posted on

Working with Data Formats: JSON, CSV, and YAML Explained

As developers, we constantly shuttle data between systems. APIs return JSON, spreadsheets export CSV, and config files use YAML. Understanding when to use each format — and how to convert between them — is a fundamental skill.

Let's break down each format, when it shines, and when it doesn't.

JSON: The Universal Language of APIs

JSON (JavaScript Object Notation) is everywhere. Every REST API speaks it. Every programming language can parse it. It's the lingua franca of web development.

{
  "user": {
    "name": "Alice",
    "age": 30,
    "roles": ["admin", "editor"],
    "active": true
  }
}
Enter fullscreen mode Exit fullscreen mode

JSON strengths

  • Universal support — every language has a JSON parser
  • Strict syntax — less ambiguity means fewer bugs
  • Nested structures — perfect for complex, hierarchical data
  • Native to JavaScript — no conversion needed in browser/Node.js

JSON pain points

  • No comments — you can't annotate your config files
  • Verbose — lots of braces and quotes
  • Trailing commas — adding one breaks everything

When working with JSON daily, a good JSON formatter saves you from squinting at minified API responses. Paste in a blob, get readable output instantly.

CSV: The Spreadsheet Bridge

CSV (Comma-Separated Values) is the oldest and simplest format. It's just rows and columns, separated by commas. Every spreadsheet app can open it, and every database can import it.

name,age,role,active
Alice,30,admin,true
Bob,25,editor,true
Carol,35,viewer,false
Enter fullscreen mode Exit fullscreen mode

CSV strengths

  • Dead simple — humans can read and write it
  • Compact — minimal overhead compared to JSON
  • Universal import — Excel, Google Sheets, databases all accept it
  • Streaming-friendly — process line by line without loading everything into memory

CSV pain points

  • No nesting — flat data only
  • No types — everything is a string
  • Delimiter hell — commas inside values need quoting, which leads to edge cases
  • No standard — RFC 4180 exists but many implementations ignore it

When to convert between JSON and CSV

The most common scenario: your API returns JSON, but your stakeholders want a spreadsheet. Or you have a CSV export that needs to feed into a JSON-based system.

A JSON to CSV converter handles this translation. It flattens nested JSON into columns and maps CSV rows back to objects.

YAML: The Human-Friendly Config Format

YAML (YAML Ain't Markup Language) was designed for configuration. It's what you see in Docker Compose files, GitHub Actions, Kubernetes manifests, and Ansible playbooks.

user:
  name: Alice
  age: 30
  roles:
    - admin
    - editor
  active: true
Enter fullscreen mode Exit fullscreen mode

YAML strengths

  • Readable — the cleanest syntax of the three
  • Comments — use # to annotate anything
  • Multi-line strings — built-in support with | and >
  • Anchors & aliases — reuse values with & and *

YAML pain points

  • Indentation-sensitive — one wrong space breaks everything
  • Implicit typingyes, no, on, off become booleans (the Norway problem)
  • Security — some parsers execute arbitrary code (always use safe loaders)
  • Complex spec — YAML 1.2 spec is surprisingly large

YAML ↔ JSON: same data, different clothes

YAML and JSON are actually interchangeable for most use cases. Every valid JSON document is also valid YAML. Converting between them is useful when:

  • You're debugging a YAML config and want to see the JSON structure
  • You need to pass YAML config values to a JSON API
  • You're migrating config formats

A YAML to JSON converter makes these translations instant.

Quick Comparison

Feature JSON CSV YAML
Nesting Yes No Yes
Comments No No Yes
Types Yes No Yes (implicit)
Human-readable Medium High High
Machine-parseable High Medium Medium
Best for APIs, data exchange Tabular data, exports Configuration

Choosing the Right Format

Here's my decision tree:

  1. Building an API? → JSON. No contest.
  2. Exporting data for non-developers? → CSV. They'll open it in Excel.
  3. Writing config files? → YAML. Comments and readability matter for config.
  4. Storing structured data? → JSON if it needs to be machine-processed, YAML if humans will edit it.

The Practical Toolkit

Working with data formats daily means you'll frequently need to:

  • Pretty-print minified JSON
  • Convert between JSON and CSV for reports
  • Translate YAML configs to JSON for debugging

Having these tools bookmarked saves real time. I keep DevToolBox open — it has all three converters plus 47 other developer tools, all free and browser-based.

Happy formatting!

Top comments (0)