JSON, YAML, CSV & XML Converter Online

Because CSV has no type system at all — every cell is just text, so there is no reliable way to tell whether "05" should become the number 5 (losing a meaningful leading zero, like a US ZIP code) or the string "05". Rather than guess and silently corrupt data like ZIP codes, phone numbers or version strings ("1.0"), this tool always keeps CSV values as strings. If you need real numbers, convert them explicitly after the fact.

CSV is inherently flat — a row of cells, nothing nested — so a nested object or array value is embedded as its JSON text inside that one cell rather than being dropped or causing an error. It round-trips as text; it just isn't broken out into further columns.

Converting to CSV needs the array's contents to be uniform — either every element is a flat object (which becomes a row, with the union of every object's keys as the header), or every element is itself an array (which becomes a row of raw cells). An array mixing objects, arrays, and plain values like strings has no single sensible row shape, so it's rejected with an explanation rather than guessed at.

Yes — CSV parsing follows RFC 4180's quoting rules, including a doubled `""` as an escaped quote inside a quoted field, and a quoted field that itself contains the delimiter or a newline. Malformed CSV, like an unterminated quote, is reported clearly rather than silently misreading the rest of the file.

There's no universal standard for this, so the tool uses one explicit, documented convention. An attribute becomes an object key prefixed with `@` (`<a id="1">` becomes `{"@id": "1"}`). Element text alongside attributes or child elements goes under a `#text` key. Repeated sibling tags, like several `<item>` elements in a row, collapse into a JSON array under that tag name — a single occurrence stays a plain value rather than a one-element array. Converting the other way round applies the same rules in reverse, so a document that started as XML round-trips back to the same XML.

It's sanitised rather than rejected — invalid characters become `_`, and a name that doesn't start with a letter or underscore gets one prefixed, so every key produces valid XML. Because XML also requires exactly one root element, a JSON array or an object with more than one top-level key gets wrapped in a `<root>` element (a top-level array becomes repeated `<item>` children of it); an object with exactly one top-level key uses that key as the root tag instead, which is what lets a document converted from XML convert cleanly back to it.

It's a convenience default, not a guarantee — it looks for clear structural signals (JSON's braces, YAML's "key:" lines or "---" markers, CSV's delimiter-separated header row) and only switches the "From" format when it finds one it's confident about; otherwise it leaves your current selection alone rather than guessing. It only runs on a drop or a paste into an empty box, never on ordinary typing, and you can always override it with the "From" selector.

Yes, five million characters — everything runs synchronously in your browser tab with no server to offload to, so an unbounded input would freeze the page with no way to show progress. That's generous enough for any config file or spreadsheet export a person would realistically paste in by hand.