Data Converter
Convert data between JSON, CSV, YAML, XML, TOML formats online. Free data format transformer with syntax validation and pretty printing
JSON, YAML, TOML, XML, and CSV all encode the same logical thing — a tree or table of values — and each is the wrong choice for at least one common use. Converting between them is mostly mechanical, except when a YAML anchor refuses to round-trip, an XML namespace gets stripped, or a CSV column with embedded commas drops fields. This converter handles all five with format-specific edge cases surfaced as warnings, not silently dropped.
What each format is actually good at
- JSON — the lingua franca. Strict type system (string, number, boolean, null, array, object), no comments in strict mode, lossless for the data model it supports. Web APIs, log files, config-as-code.
- YAML — human-friendly with comments and references. Indentation-sensitive (a 4-space file in a 2-space repo is a different document). The "Norway problem" (the country code "NO" being parsed as boolean false in YAML 1.1) is the textbook gotcha. YAML 1.2 fixed it but most parsers still ship 1.1 semantics.
- TOML — config files. Less expressive than YAML, less verbose than JSON. Strict types, comments allowed, no anchors, no implicit type coercion. Used by Cargo, pyproject.toml, hugo.toml.
- XML — verbose but powerful. Namespaces, schemas (XSD), attributes vs children, mixed content (text and elements interleaved). Legacy enterprise, SOAP, Office Open XML, sitemap.xml.
- CSV — flat tabular only. No types (everything is a string), no nesting. Spreadsheet-friendly. RFC 4180 specifies escaping rules (double-quote-doubled inside quoted fields) but real-world CSV is dialect chaos.
Working example: JSON to YAML round-trip
Input
JSON:
{
"service": {
"name": "api",
"replicas": 3,
"ports": [80, 443],
"debug": true,
"ratio": 0.5
}
}Output
YAML:
service:
name: api
replicas: 3
ports:
- 80
- 443
debug: true
ratio: 0.5
Round-trip warnings:
- YAML 1.1 parsers may parse "on", "off", "yes", "no" as booleans even when meant as strings. None of these appear here.
- A string value of "0.5" (with quotes) and a number 0.5 round-trip differently — JSON preserves the distinction; YAML's plain-scalar 0.5 always means number.YAML preserves the data but not the JSON-specific quoting. If you need byte-for-byte round-trip, use JSON. If you need readability with comments, use YAML and accept that round-trip through JSON drops the comments.
Conversion gotchas that bite in production
- CSV nesting — there is no good way to put JSON inside CSV. Embedded objects flatten (dot notation: user.name) or get JSON-stringified into a single cell, which then needs escaping. Decide once per dataset and document it.
- JSON Date — JSON has no date type. ISO 8601 strings are convention, not enforced. Round-tripping through YAML may convert "2024-01-01" to a date object (depending on YAML library), losing string-ness.
- XML attribute vs child — <user id="42"><name>Ada</name></user> versus <user><id>42</id><name>Ada</name></user>. JSON cannot distinguish; conversions choose a convention (Badgerfish, @attr keys, etc.) and stick with it.
- CSV BOM — UTF-8 CSV with a BOM at the start breaks several common parsers (Python's csv.reader treats the BOM as part of the first column name). Strip BOM on input or document that yours has one.
- YAML duplicate keys — YAML 1.2 says duplicate keys are an error; many parsers silently take the last one. JSON spec says behavior is undefined. If your input has duplicates, decide which copy "wins" before converting.
- TOML arrays of tables — [[servers]] is a list of objects. Converting to JSON yields { "servers": [...] }; converting back from JSON requires the convention that array-of-objects-with-string-keys becomes [[table]] sections.
When to reach for this tool
- You inherited a deployment using TOML config and need to migrate to YAML (or vice versa) without missing a key.
- You are exporting data from one system that emits JSON and importing into one that wants CSV — including handling embedded objects gracefully.
- You are converting an OpenAPI spec from YAML to JSON for a tool that only reads JSON (or vice versa).
- You need to flatten a deep XML response into a CSV for a spreadsheet review.
What this tool will not do
- It will not preserve YAML comments through other formats. Comments are not in the data model of JSON, TOML, or XML. Round-trip yaml→json→yaml drops them.
- It will not produce schema-validated XML. The output is well-formed but not necessarily valid against any XSD. For SOAP / signed XML / schema-bound formats, generate with a real serializer that knows the schema.
- It will not handle CSV dialect detection perfectly. Auto-detection works for comma-separated UTF-8 with RFC 4180 quoting. Tab-separated, semicolon-separated (German Excel), and quote-escaped-by-backslash all need explicit dialect selection.
Conversion happens entirely in your browser. Customer data, internal configs, and production payloads stay local.
Frequently asked questions
Why is my YAML number quoted as a string in the JSON output?
The YAML parser preserved string-ness because the original had quotes ("42" vs 42). Plain scalar 42 in YAML round-trips to number 42 in JSON; the quoted form survives as string. Strip quotes in the YAML source if you want number output.
How does CSV handle commas inside fields?
RFC 4180: wrap the field in double quotes. To include a literal double quote, escape it by doubling: "She said ""hi""". Real-world CSV often uses \" instead — which RFC 4180 does not allow. Most parsers handle both; both produce ambiguity if the data also contains backslashes.
Why does XML output have extra whitespace?
Default pretty-printing adds indentation for readability. Most XML parsers ignore inter-element whitespace, but mixed-content XML (where text is intentional inside elements) is sensitive to it. Disable pretty-printing for round-trippable, byte-stable output.
Can JSON represent everything YAML can?
Almost. YAML's extras: comments, anchors (&name) and aliases (*name) for shared structure, multi-document streams (--- separators), explicit type tags (!!str, !!binary). JSON has none of these; conversions either drop or expand them.
Which format is fastest to parse?
JSON, by a wide margin. Native JSON parsers exist in every modern runtime, written in C and SIMD-optimized in some cases. YAML is ~10x slower; TOML is fast but parsers are less optimized; XML is slowest. For high-throughput pipelines, prefer JSON unless you specifically need a feature of another format.
How do I keep types intact when round-tripping?
JSON ↔ JSON is exact (modulo number precision in JSON's float64). JSON ↔ TOML is mostly exact (TOML adds date types). JSON ↔ YAML loses YAML-specific structure (anchors, comments). JSON ↔ XML requires a convention for attributes vs children. JSON ↔ CSV is lossy for any nested structure.
Related tools
Format and beautify JSON, XML, CSS, HTML, JavaScript, SQL code. Auto-indent and syntax highlight. Free online code beautifier and formatter
Compare two JSON documents with visual tree diff. Highlight added, removed, modified nodes. Expandable tree view. Free online JSON comparison tool
Generate JSON Schema from example JSON data automatically. Create validation schemas for APIs. Free online JSON Schema builder for developers
Generate TypeScript interfaces from JSON data. Support for nested objects, arrays, optional properties. Free online JSON to TS interface generator
Create beautiful charts from CSV or JSON data. Bar, line, pie, scatter, area charts. Export as PNG or SVG. Free online chart maker
Advanced spreadsheet-like table editor. Sort, filter, search data. Basic formulas support. Import/export CSV, JSON. Free online data grid editor
Last updated · E-Utils editorial team