JSON to CSV, CSV to JSON, XML to JSON, YAML to JSON — convert between all major data formats instantly in your browser. Free, no signup, handles large files.
Last Tuesday at 2 AM, I was staring at a 47MB JSON file from a client's API. They needed it in CSV for their analytics team, who only speak Excel. The JSON had nested objects three levels deep, arrays inside arrays, and inconsistent field names. My deadline was 8 AM.
If you've ever had to convert data between formats, you know this feeling. It should be simple. Copy, paste, done. Except it never is. The nested objects explode into weird column names. The special characters break. The encoding goes sideways. The 50,000-row file makes your browser tab crash.
This guide is everything I've learned about converting between JSON, CSV, XML, and YAML without losing your mind or your data.
Every format was invented to solve a specific problem. CSV was designed for tabular data that spreadsheets could read. XML was designed for document markup that machines and humans could both parse. JSON was designed for lightweight data interchange on the web. YAML was designed for configuration files that humans actually want to read.
The problem is that data doesn't stay in one place. Your API returns JSON, but your business team wants Excel. Your microservice config is in YAML, but your deployment tool needs JSON. Your legacy system exports XML, but your modern frontend expects JSON.
| Format | Best For | Weakness |
|---|---|---|
| JSON | APIs, web apps, NoSQL databases | No native date type, no comments |
| CSV | Spreadsheets, flat tabular data | No nested data, no types |
| XML | Enterprise systems, SOAP, documents | Verbose, complex parsing |
| YAML | Config files, DevOps pipelines | Indentation-sensitive, type coercion |
JSON won the data format wars for web development. It's what your REST API returns, what your NoSQL database stores, and what your frontend consumes.
Akousa{
"employees": [
{
"id": 1,
"name": "Sarah Chen",
"department": "Engineering",
"skills": ["Python", "Rust", "SQL"],
"address": {
"city": "Portland",
"state": "OR"
}
}
]
}JSON has five data types: strings, numbers, booleans, arrays, and objects. This simplicity is both its strength and weakness. It's lightweight (30-50% smaller than equivalent XML) and every language has native JSON support.
The lack of a date type means dates get stored as strings — "2026-03-23", "2026-03-23T14:30:00Z", or even Unix timestamps. When converting between formats, date handling is consistently the number one source of bugs. No comments means you can't annotate your JSON files, which is why configuration often prefers YAML.
CSV is the oldest format here and the most misunderstood. Everyone thinks CSV is simple. It's not.
id,name,department,skills,city,state
1,Sarah Chen,Engineering,"Python, Rust, SQL",Portland,ORHere's something most people don't know: there is no single CSV standard. RFC 4180 exists, but it's a memo, not a binding specification.
""), others use backslashes\n, \r\n, or \rCSV is perfect when your data is genuinely flat: product catalogs, user lists, transaction logs. Every database and spreadsheet on earth can import CSV. But the moment your data has nesting, CSV struggles. How do you represent an array of skills in a cell? A nested address object? There's no standard answer.
XML was supposed to be the universal data format. In the early 2000s, everything was XML. It's still critical in healthcare (HL7), finance (SWIFT/ISO 20022), and government systems.
<employee id="1" active="true">
<name>Sarah Chen</name>
<department>Engineering</department>
<skills>
<skill>Python</skill>
<skill>Rust</skill>
</skills>
</employee>XML has capabilities JSON doesn't: attributes on elements, namespaces for preventing naming collisions, XSD schema validation, and XSLT transformations. The tradeoff is verbosity — the XML version of any dataset is roughly 3x the size of JSON.
YAML is what JSON would look like if designed for humans. It's the default for Kubernetes manifests, Docker Compose, GitHub Actions, and Ansible.
employees:
- id: 1
name: Sarah Chen
department: Engineering
skills:
- Python
- Rust
- SQL
address:
city: Portland
state: ORNo curly braces, no commas, comments with #, multi-line strings. But YAML has infamous parsing surprises: NO (the country code) becomes boolean false. 1.0 becomes a float, not the string "1.0". Zip code 97201 becomes an integer unless quoted. Tabs are forbidden.
This is the conversion most people search for, and the one with the most pitfalls.
Flat JSON arrays convert cleanly:
[
{"id": 1, "name": "Widget A", "price": 9.99, "stock": 150},
{"id": 2, "name": "Widget B", "price": 14.99, "stock": 75}
]id,name,price,stock
1,Widget A,9.99,150
2,Widget B,14.99,75Keys become headers, values become cells. Life is good.
Real-world JSON is rarely flat. Here's where a json to csv converter needs to be smart:
[
{
"orderId": "ORD-001",
"customer": {"name": "Alice Park", "email": "alice@example.com"},
"items": [
{"product": "Laptop", "qty": 1, "price": 999},
{"product": "Mouse", "qty": 2, "price": 29}
],
"shipping": {"city": "Seattle", "method": "express"}
}
]Three common flattening strategies:
Strategy 1 — Dot Notation: Flatten nested objects by joining keys with dots. customer.name, customer.email, shipping.city. Works for objects, but doesn't handle the items array.
Strategy 2 — Array Expansion: Create a row for each array element, duplicating parent data. One order with 5 items becomes 5 CSV rows. Accurate but increases file size.
Strategy 3 — Array Indexing: Use numbered columns: items.0.product, items.1.product. Keeps one row per order but creates sparse columns when array sizes vary.
Which to choose? Array expansion for database imports, dot notation for business reporting, array indexing for quick inspection. On akousa.net's JSON to CSV converter, you can choose your strategy before converting.
Going the other direction has its own challenges.
CSV has no types. Every cell is a string. Is "42" a string or number? Is "true" a string or boolean?
name,age,active,score
Alice,28,true,95.5
Bob,35,false,87.0Naive conversion keeps everything as strings. Smart conversion detects numbers and booleans:
[
{"name": "Alice", "age": 28, "active": true, "score": 95.5},
{"name": "Bob", "age": 35, "active": false, "score": 87.0}
]But type inference can be wrong. If age is a string ID like "007", inference strips leading zeros. Good csv to json converters let you override detection per column.
If your CSV headers use dot notation, some converters can rebuild the structure:
name,address.street,address.city
Alice,123 Oak Ave,PortlandBecomes nested JSON with address as an object. The CSV to JSON converter on akousa.net supports this, saving hours of manual restructuring.
This conversion is trickier than it looks because of fundamental structural differences.
XML elements can have attributes. JSON objects just have properties.
<price currency="USD">79.99</price>Where does currency go in JSON? Convention 1 uses @ prefixes ("@currency": "USD"). Convention 2 flattens it ("priceCurrency": "USD"). Convention 1 is lossless — you can round-trip back to XML. Convention 2 is cleaner but destructive.
This is one of XML-to-JSON conversion's nastiest edge cases:
<!-- One tag: converter produces a string -->
<tags><tag>audio</tag></tags>
<!-- Two tags: converter produces an array -->
<tags><tag>audio</tag><tag>bluetooth</tag></tags>The tag field's type changes based on element count. Your code that does data.tags.tag.forEach(...) works for two tags but crashes for one. Good xml to json converters let you force certain elements to always be arrays.
Since YAML is a superset of JSON, this conversion is the most straightforward — but type coercion creates surprises.
name: Project Config
version: 1.0
debug: yes
ports:
- 8080
- 443{
"name": "Project Config",
"version": 1.0,
"debug": true,
"ports": [8080, 443]
}yes became true (YAML boolean coercion). 1.0 became a float. Going JSON to YAML is typically motivated by readability — the same CI/CD pipeline definition becomes dramatically more readable in YAML. The YAML tools on akousa.net handle this while warning about type coercion issues.
Note: YAML to JSON loses comments (JSON doesn't support them). Plan accordingly.
{"message": "He said \"hello\" and she said 'goodbye'"}In CSV, double quotes inside a quoted field get doubled: "He said ""hello"" and she said 'goodbye'". Most tools handle this, but some don't, silently corrupting data.
A literal newline inside a CSV cell requires the cell to be quoted. Many simple parsers split on newlines first, breaking multiline values entirely. Test with a sample before processing full datasets.
JSON is always UTF-8. CSV might be anything. Convert JSON to CSV, open in Excel, and you might see é instead of é because Excel assumed Windows-1252. Fix: add a UTF-8 BOM at the start of the CSV file.
[
{"name": "Alice", "phone": null},
{"name": "Bob"},
{"name": "Carol", "phone": "555-0123"}
]In CSV, both null and missing keys become empty cells. The distinction is lost. If downstream systems treat these differently, you need a convention.
Three levels of nesting (arrays inside arrays inside arrays) has no clean CSV representation. The pragmatic approach: split into multiple CSV files with foreign key relationships, essentially denormalizing the data.
For a 100MB JSON file, browser-based converters need 400-800MB of memory (raw text + parsed objects + output). Modern browser tabs get 1-4GB, so files up to ~200MB usually work. The converters on akousa.net use streaming parsing to keep memory proportional to the current chunk.
jq:
jq -r '(.[0] | keys_unsorted) as $keys | $keys, (.[] | [.[$keys[]]]) | @csv' data.json > output.csvMiller (mlr):
mlr --json --ocsv cat data.json > output.csv
mlr --csv --ojson cat data.csv > output.jsonPython:
import json, csv
with open('data.json') as f:
data = json.load(f)
with open('output.csv', 'w', newline='') as f:
writer = csv.DictWriter(f, fieldnames=data[0].keys())
writer.writeheader()
writer.writerows(data)For files under 200MB, browser tools are faster. For anything bigger, jq and mlr are your friends.
One of the most common scenarios: taking API JSON and getting it into Excel.
The critical step is flattening. If the API returns nested attributes.pricing.amount, you want that as a column header, not a JSON blob in a cell.
People searching for "convert json to excel" usually go JSON to CSV to Excel. The gotcha: Excel guesses types during CSV import, turning zip codes into numbers and stripping leading zeros.
Better approach: use Excel's "Import Data" feature instead of "Open File" — it lets you specify column types during import. Or use a converter that handles quoting and type preservation automatically.
MongoDB exports JSON. PostgreSQL imports CSV. The path: export JSON, flatten nested documents to match your relational schema, convert to CSV, import with \copy.
Moving Spring Boot XML config to YAML, or converting JSON Kubernetes manifests to YAML. Small files where accuracy matters more than speed. Always validate the output — an incorrect Kubernetes manifest means a failed production deployment.
Your product team maintains inventory in Google Sheets. Your API accepts JSON. The workflow: export the Sheet as CSV, run it through a csv to json online converter with type inference enabled, review the output for type correctness, and use it as your API payload. What used to require a custom Python script now takes 30 seconds.
You need to export a PostgreSQL table, transform some fields, and reimport. Export as CSV, convert to JSON for easier manipulation with jq or JavaScript, make your transformations, convert back to CSV, reimport. The JSON intermediate format makes complex transformations much easier than trying to manipulate CSV directly.
Not checking output. Always spot-check: first 10 rows, last 10 rows, 10 random rows from the middle. Verify row count matches. Two minutes of checking saves two days of debugging.
Losing number precision. A 64-bit integer like 9007199254740993 exceeds JavaScript's safe integer limit. Excel silently rounds it. Treat large integers as strings.
Assuming consistent structure. Three JSON objects with different key sets? A naive converter uses only the first object's keys, silently dropping fields from later records. Good converters scan all objects for the complete column set.
Encoding mismatch. JSON is UTF-8. CSV target is unclear. Your colleague in Japan opens it and every character is garbled. Always use UTF-8 with BOM for Excel compatibility.
Wrong root path. Not all JSON is an array. Some wraps data in {"metadata": {...}, "results": [...]}. Point the converter at results, not the root object.
Let me share complete workflows for the most common scenarios.
Your monitoring API returns JSON. Management wants a weekly Excel report.
Total time: under 2 minutes for files up to 50MB.
A partner sends XML data feeds daily. Your system needs JSON.
@ for lossless conversion)Your CI/CD config is in JSON but your team wants readable YAML.
When you have dozens or hundreds of files, doing them one by one isn't practical.
# Convert all JSON files in a directory to CSV
for f in *.json; do
mlr --json --ocsv cat "$f" > "${f%.json}.csv"
doneSometimes you need to combine multiple JSON files into one CSV:
jq -s 'add' file1.json file2.json file3.json | \
jq -r '(.[0] | keys_unsorted) as $k | $k, (.[] | [.[$k[]]]) | @csv' > merged.csvOr multiple CSVs into a single JSON:
# Keep header from first file, data from all
head -1 file1.csv > merged.csv
for f in file*.csv; do tail -n +2 "$f" >> merged.csv; done
# Then convert merged.csv to JSON with your preferred toolimport json, csv, glob
for filepath in glob.glob('data/*.json'):
with open(filepath) as f:
data = json.load(f)
csv_path = filepath.replace('.json', '.csv')
with open(csv_path, 'w', newline='') as f:
# Collect all keys across all records
all_keys = set()
for record in data:
all_keys.update(record.keys())
writer = csv.DictWriter(f, fieldnames=sorted(all_keys))
writer.writeheader()
writer.writerows(data)Note how this script collects all keys across all records — avoiding the "inconsistent structure" mistake mentioned earlier.
Conversion without validation is gambling.
Row count check:
jq length input.json # JSON array length
wc -l output.csv # CSV rows (subtract 1 for header)Round-trip testing — the gold standard: convert A to B to A and diff with the original. If the diff is empty, your conversion is lossless.
diff <(jq -S . original.json) <(jq -S . roundtripped.json)Schema validation for JSON output: use JSON Schema to enforce required fields, types, and formats.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": {
"type": "object",
"required": ["id", "name", "email"],
"properties": {
"id": {"type": "integer"},
"name": {"type": "string"},
"email": {"type": "string", "format": "email"}
}
}
}Spot-check protocol: Look at the first 10 rows, the last 10 rows, and 10 random rows from the middle. Check that special characters survived. Verify numeric precision. This takes two minutes and catches problems that automated checks miss.
Column/field completeness: For CSV output, verify every row has the same number of fields as the header. For JSON output, confirm all expected keys are present. Missing columns usually mean the converter encountered an unexpected structure and silently dropped data.
To set realistic expectations, here are rough timelines for browser-based data format conversion:
| File Size | Records | JSON to CSV | CSV to JSON | XML to JSON |
|---|---|---|---|---|
| 1 MB | ~5,000 | < 1 second | < 1 second | 1-2 seconds |
| 10 MB | ~50,000 | 2-5 seconds | 2-5 seconds | 5-10 seconds |
| 50 MB | ~250,000 | 10-20 seconds | 10-20 seconds | 20-40 seconds |
| 100 MB | ~500,000 | 20-45 seconds | 20-45 seconds | 40-90 seconds |
| 200 MB+ | 1M+ | Use CLI tools | Use CLI tools | Use CLI tools |
These are approximate and depend on data complexity (nesting depth, field count) and your machine's RAM. Flat data converts faster than deeply nested structures.
Use JSON for REST APIs, document databases, web service data interchange, variable-structure data.
Use CSV for flat tabular data, Excel/Sheets compatibility, SQL database imports, maximum legacy interoperability.
Use XML for enterprise/government integration, SOAP APIs, schema-validated documents, XSLT pipelines.
Use YAML for configuration files humans maintain, Kubernetes/Docker/CI/CD, anything needing comments and readability.
Many online converters upload your data to a server. If your JSON contains customer emails, API keys, or financial data, you're sending it to a third party. The converters on akousa.net process everything in your browser — your data never leaves your machine. For highly confidential data, command-line tools are the safest option.
Yes, but you need to choose a flattening strategy. Dot notation works for nested objects. For arrays, you either expand rows (one row per array element), use indexed columns (items.0, items.1), or join array values with a delimiter. The best choice depends on what you're doing with the CSV.
It depends on the conversion direction. JSON to YAML and back is essentially lossless (except comments). JSON to CSV loses nesting structure and type information. XML to JSON can lose attribute/element distinction and namespace information. Always do a round-trip test if data integrity is critical.
JSON has no date type, so dates are always strings. When converting CSV to JSON, dates should remain as strings in ISO 8601 format ("2026-03-23" or "2026-03-23T14:30:00Z"). When converting to CSV, dates pass through unchanged. The danger zone is opening CSV in Excel, which may reformat dates based on your locale settings.
Typically 100-200MB before you risk the browser tab running out of memory. It depends on data complexity — flat arrays of simple objects handle better than deeply nested structures. For anything larger, command-line tools like jq, mlr, or Python scripts are more reliable.
Use a converter that quotes string fields, then use Excel's "Import Data" feature (Data tab > From Text/CSV) instead of double-clicking the file. The import wizard lets you set each column's data type, preventing Excel from treating zip codes or IDs as numbers.
Data format conversion seems simple until it isn't. The happy path is easy: flat JSON to CSV, YAML to JSON. The real world gives you nested objects, inconsistent schemas, special characters, massive files, and encoding mismatches.
The principles I keep coming back to:
That 47MB JSON file I mentioned at the beginning? Converted in under 30 seconds, nested objects flattened correctly, all 50,000 records intact, ready for the analytics team by 2:15 AM. Sometimes the right tool really does make all the difference.