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 parsing complexity — YAML has many edge cases (the "Norway problem" where NO becomes boolean false, leading-zero numbers being octal, types implicitly inferred from value content) that can produce surprising bugs. Use YAML when the file gets edited by hand more than it gets 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 — the same data in XML is typically 30-50% larger than JSON. For new code, almost no one chooses XML; for integrating with existing systems that already speak it, XML 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

JSON ↔ YAML round-trips losslessly for most data. JSON → XML loses semantic distinction between attributes and elements (the tool picks one convention). XML → JSON loses XML namespaces and the attribute/element distinction. JSON → CSV requires the data to be an array of objects (anything else gets flattened or errors). CSV → JSON makes everything a string (you'll need to retype numbers and booleans yourself). Plan the direction of conversion before designing your data model — going JSON → XML → JSON usually doesn't round-trip cleanly.