Converter

When you'd use it

• Turning a JSON API response into YAML for a Kubernetes manifest or a CI config.
• Converting a CSV export into JSON so you can seed a database or a fixture file.
• Reading an XML response from a legacy service by converting it to JSON first.
• Migrating a config file from JSON to TOML when a tool changes its expected format.
• Flattening JSON records into CSV to hand to someone who works in a spreadsheet.

JSON to YAML

YAML drops the punctuation and uses indentation, which is why config files favour it.

{
  "service": "api",
  "replicas": 3,
  "ports": [8080, 8443],
  "env": { "LOG_LEVEL": "debug" }
}

service: api
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: debug

CSV to JSON

The header row becomes object keys. Every value arrives as a string, because CSV has no types.

name,team,active
Ada,Platform,true
Grace,Compilers,false

[
  { "name": "Ada", "team": "Platform", "active": "true" },
  { "name": "Grace", "team": "Compilers", "active": "false" }
]

These formats are not equivalent, and conversion is lossy

Converting between formats is not a rename. Each format can express things the others cannot, and anything outside the target's model has to be dropped or approximated. Knowing where the losses are saves a lot of confused debugging.

• JSON has six types: object, array, string, number, boolean, null. It has no dates, no comments, and no integer/float distinction.
• YAML is a superset of JSON with comments, anchors and aliases for reuse, multi-line block scalars, and multiple documents in one file. Converting YAML to JSON discards comments and expands anchors into duplicated content.
• XML has attributes, namespaces, mixed content, and ordered sibling elements — none of which map cleanly onto a JSON object. Repeated sibling elements become an array; a single element cannot be distinguished from a one-element array.
• CSV is a flat table with no types and no nesting. Converting nested JSON to CSV either flattens paths into column names or drops the nested parts.
• TOML has first-class dates and times and a strict table model, but it cannot represent an array of mixed types or a document whose root is an array.

The YAML gotchas worth knowing

YAML's convenience comes from aggressive type inference, and that inference has famous edge cases. In YAML 1.1, the bare words yes, no, on, and off parse as booleans — the "Norway problem", where the country code NO becomes false. A version number like 1.20 parses as the number 1.2. A leading zero can make a number parse as octal. Anything ambiguous should be quoted.

Indentation must use spaces; tabs are illegal in YAML and produce a parse error that often points at the wrong line. If a YAML file will not parse and looks correct, check for a tab first.

CSV: types, commas, and quotes

CSV carries no type information. Every field is text, so the boolean true and the string "true" are indistinguishable, and so are the number 007 and the string "007" — except that many tools will silently turn the latter into 7 and destroy a zip code or a part number.

The escaping rules are the other source of trouble. A field containing a comma, a double quote, or a newline must be wrapped in double quotes, and a literal double quote inside such a field is written as two double quotes. A CSV that breaks halfway through usually has an unescaped quote somewhere above the break.

XML to JSON: the attribute problem

XML distinguishes attributes from child elements; JSON has no such distinction. Converting requires a convention, and this tool prefixes attribute names so they do not collide with element names of the same name.

The other asymmetry is arrays. In XML, one <item> and three <item> elements are structurally the same thing, and only a schema tells you which is expected. Converting a single element produces an object rather than a one-element array, which is why code that consumes converted XML should tolerate both.

Frequently asked questions

Why is a format pair greyed out?

Because the conversion has no sensible interpretation. CSV is flat, so converting arbitrary nested XML to CSV would silently discard most of the document. The supported list at the bottom of the page shows every valid pair; some route through JSON internally, which is why they behave like JSON in edge cases.

Is my data sent to a server?

No. Parsing and serialisation both run in your browser. That is deliberate — config files are exactly the kind of thing that contains connection strings and API keys.

My comments disappeared converting YAML to JSON.

JSON has no comment syntax, so there is nowhere to put them. This is a real loss, not a bug — keep the original if the comments matter, or convert in the other direction where possible.

Numbers lost precision. Why?

JSON numbers are IEEE 754 doubles, which represent integers exactly only up to about 9 quadrillion. Snowflake IDs and some database identifiers exceed that and get rounded. The standard fix is to carry those values as strings.

Can I convert nested JSON to CSV?

Only if it is an array of flat objects. Nested structures have no representation in a flat table — flatten them first, in the JSON Editor's query bar, and then convert.