Data-Format Converter (JSON ↔ CSV / YAML / XML)

Nested objects are flattened into dotted-path columns: {"user":{"name":"Ada"}} becomes a column named user.name. The header row is the union of every key seen across all rows, in first-seen order, so rows with different shapes still line up. Values that are still objects or arrays after flattening are written as a JSON string inside the cell rather than being silently dropped.

Per RFC 4180. A field that contains the delimiter (comma or tab), a double quote, or a line break is wrapped in double quotes, and any double quote inside the field is escaped by doubling it (" becomes ""). The parser is a full RFC-4180 state machine, so it correctly reads quoted fields that themselves contain commas, escaped quotes and embedded newlines.

When converting CSV or TSV into another format, the tool can coerce cell text into real types: "42" becomes the number 42, "true"/"false" become booleans, and "null" becomes null. This is convenient but occasionally wrong — for example a leading-zero code like "007" or an ID would become 7. Toggle type inference off to keep every cell as a string, which is the safe choice for identifiers, phone numbers and zip codes.

No. The converter follows YAML 1.2, which is a strict superset of JSON. In the old YAML 1.1 spec, unquoted no, yes, on and off were parsed as booleans — so a list of country codes containing NO (Norway) silently became false. YAML 1.2 removed those implicit conversions, so only true/false are booleans and country codes survive as strings. YAML and JSON round-trip to identical data.

Elements become objects. Repeated child tags collapse into an array — <r><item>1</item><item>2</item></r> becomes {"r":{"item":["1","2"]}}. Attributes are surfaced as keys prefixed with @_ , so <user id="1"/> becomes {"user":{"@_id":"1"}}. Tag and attribute text is kept as raw strings so numeric-looking values are not coerced. Building XML back from JSON mirrors the same @_ attribute convention.

Yes. Choosing TypeScript as the target infers an interface from a sample JSON object: strings become string, numbers number, booleans boolean, arrays infer their element type from the first element (an empty array becomes unknown[]), and nested objects become inline object-literal types. It is a fast starting point for typing an API response — review optional/nullable fields yourself, since a single sample cannot show which keys are missing on other records.

No. Parsing and serialising both run entirely in your browser — your data is never sent to a server, logged or stored, and the tool works offline once loaded. That makes it safe to paste a real API payload or config file, which is exactly the case where server-side converters are risky.