CSV / JSON Converter

How RFC 4180 defines CSV

CSV has no single universal standard, but RFC 4180 (October 2005, "Common Format and MIME Type for Comma-Separated Values (CSV) Files") is the de facto baseline. It registers the text/csv MIME type and pins down three rules that naive split-on-comma parsers get wrong:

Fields containing a comma, a double quote, or a line break must be wrapped in double quotes. Inside a quoted field, a literal double quote is escaped by doubling it — "". Records are separated by CRLF, and a header row is conventional but not mandatory. RFC 4180 also declares fields as text — there is no native type information, so the number 41 and the string "41" are indistinguishable until a converter applies a type.

• Quoted field: "Smith, John" — one field, not two
• Escaped quote: "He said ""hi""" — value is He said "hi"
• Embedded newline: a quoted field may legally span multiple physical lines

Why the CSV-to-JSON mapping is not lossless

CSV is a flat table of rows and columns; JSON is a tree that can nest arbitrarily deep. Converting CSV to JSON therefore forces a representational choice. The common convention — treating the header row as object keys and each data row as values — produces a flat array of flat objects. That works for a product list, but it cannot round-trip nested structures like { "address": { "city": "Berlin" } } without a schema or dot-notation convention such as address.city.

The reverse direction loses even more. A JSON document with mixed-shape array elements, nested objects, or varying keys cannot be squared into a uniform column grid. When you convert JSON to CSV, decide which fields to project and how to flatten nesting before you click convert.

# Flat CSV round-trips cleanly:
name,age
Ada,36            ->  [{ "name": "Ada", "age": "36" }]

# Nested JSON does NOT map to CSV without a flatten rule:
[{ "user": { "name": "Ada" } }]   ->   needs user.name projection

Delimiters and encoding pitfalls

Comma is the RFC 4180 default, but regional Excel installs in much of Europe use semicolon as the list separator and emit name;age. Tab-separated values (TSV) use \t. A converter that only splits on commas will silently mangle semicolon-delimited European files — always confirm the delimiter against the source before parsing.

Encoding matters too. RFC 4180 allows any character set, but UTF-8 is the only safe choice for data crossing systems. Watch for a leading byte-order mark (BOM, U+FEFF): it is invisible in editors but appears as a stray character on the first header key ("\uFEFFname"), which then fails to match the expected "name" field.