JSON / YAML / XML / CSV Converter

Data interchange formats are not interchangeable. JSON dominates web APIs and JavaScript ecosystems. YAML dominates devops config (Kubernetes, Docker Compose, GitHub Actions). XML still rules in older enterprise integrations, financial messaging (FIX, ISO 20022), and document publishing (Word, RSS, Atom). CSV is the universal spreadsheet exchange format despite being technically the worst-defined of the four. Knowing when each is the right choice — and when conversion is lossy — saves hours of integration debugging.

JSON — the default for new code

JSON (ECMA-404, 2013) is the right choice for new APIs, configuration files in JavaScript/TypeScript projects, and any data exchange where machine-parsing matters more than human readability. It's small (no closing tags), unambiguous (every value has exactly one type representation), and supported natively by every modern programming language. The trade-offs: no comments (a real pain for config files), no multi-line strings without escaping, integers are limited to 53-bit precision in JavaScript engines (a problem for Snowflake IDs and 64-bit Bitcoin satoshi values). Use JSON when machines read it more than humans do.

YAML — when humans edit the file

YAML 1.2 (2009) was designed for human-edited configuration. It supports comments, multi-line strings, anchors and aliases (DRY config), and a less-noisy syntax than JSON. It's why Kubernetes manifests, Docker Compose files, GitHub Actions workflows, and Ansible playbooks all use YAML. The cost is that types are inferred from what a value looks like, so the text you wrote and the value you get are not always the same thing. Which surprises apply depends on the YAML version: the famous ones — NO becoming false, yes/on/off becoming booleans, 12:30:00 becoming a sexagesimal number — are YAML 1.1 behaviours and do not happen here, because the library this page loads parses under 1.2's core schema. Two that do happen are worth knowing, and both were checked against the loaded library rather than assumed. mode: 0777 parses as the decimal number 777, not as an octal permission — write 0o777 or quote it. And a bare 2026-09-13 is read as a timestamp, so converting to JSON yields "2026-09-13T00:00:00.000Z", a different string from the one you typed. Use YAML when the file is edited by hand more than it is generated by code.

XML — when you can't choose

XML (1998, refined 2008) remains entrenched in financial messaging (SWIFT MX, FIX protocol), document publishing (DOCX, ODT, RSS, Atom feeds), and older enterprise B2B (SOAP web services). Its strengths are namespaces (so XML documents can mix vocabularies from different schemas), attributes vs elements (semantic distinction), and the most-developed schema/validation ecosystem (XSD, DTD, RELAX NG). Its weakness is verbosity — every element is named twice — though how much larger a document gets depends entirely on how deeply it nests and how long the tag names are, so the percentages people quote are not worth repeating. For new code XML is rarely chosen; for talking to systems that already speak it, conversion remains useful.

CSV — the eternal compromise

CSV looks simple — comma-separated values, one row per line — but the simplicity is illusory. Different tools disagree about how to escape commas inside fields (some use double-quoting, some use backslash-escape), how to handle newlines inside fields, whether the first row is headers or data, and what character encoding the file uses (UTF-8 vs Latin-1 vs UTF-8-with-BOM). RFC 4180 (2005) specifies a canonical CSV form but is widely ignored. Excel's CSV export uses CRLF line endings and double-quote escaping; Linux tools usually produce LF endings; semicolons replace commas in some European locales. The tool above outputs RFC 4180-compliant CSV when converting from JSON arrays of objects.

Conversion is lossy

All four conversions here go through one in-memory value, so what survives is whatever that value can hold. The specific losses, read off this tool's own code rather than described in general:

XML attributes are not converted — they are discarded. The XML reader walks child elements and text only, so <user id="7">Alice</user> becomes "Alice" and the id is gone. That includes xmlns declarations, so namespaces go with them. The writer never emits an attribute either, which means XML → JSON → XML cannot preserve one even in principle.

XML has no arrays, so the reader guesses. A tag appearing more than once under the same parent becomes a list; a tag appearing once becomes a scalar. A collection that happens to contain a single item therefore comes back as an object rather than a one-element array — the classic reason a consumer breaks on the smallest input.

XML text is retyped by pattern. Anything matching all digits becomes a number, so a leading-zero identifier such as 007 comes back as 7; the literal text true and false become booleans. A product code and a quantity are indistinguishable to the reader.

CSV is strings in both directions. Reading CSV gives you an array of objects whose every value is text — numbers and booleans have to be retyped by you. Writing CSV requires an array of objects and refuses anything else, with the union of all keys as the header row; a nested value is written as embedded JSON rather than expanded.

Comments never survive, in any direction — including YAML to YAML. The YAML path is load-then-dump, so the round trip rebuilds the document from the parsed value and every comment is dropped. This page cannot be used to reformat a commented configuration file.