JSON to CSV and CSV to JSON Converter

Why a naive split on commas falls apart on real CSV

The first CSV converter most of us write is one line: split on newlines, split on commas, done. It works for about a week. Then someone exports a customer named "Lovelace, Ada" and your columns shift one to the right for that row only. Good luck spotting that in 40,000 lines.

Real CSV, the RFC 4180 kind, allows three things a naive split can never survive: the delimiter inside a quoted field, a literal line break inside a quoted field, and a quote character escaped by doubling it. That last one means "She said ""hi""" is a single field. A regex can't track whether you're inside quotes; you need state. So this tool walks the file one character at a time, flipping between "inside quotes" and "outside quotes", and only treats a comma or newline as structure when it's outside. Slower to write, boring to test. Worth it.

Honestly, I think half the "CSV is a terrible format" complaints out there are really "my parser was a split() call" complaints. The format is fine. Crusty, but fine.

Flattening nested JSON: the honest tradeoffs

A spreadsheet is flat. Your JSON probably isn't. Something has to give, and here's how this tool gives: nested objects become dot keys, so a user object holding a city of Lyon turns into a column named user.city. Arrays get joined into one cell with a pipe character. If an array holds objects, each object is stringified as JSON before joining, which looks rough in Excel but at least loses nothing silently.

Is that lossy? Yes, slightly. Convert back and you'll get flat objects with dot-named keys, not the original nesting. The pipe join also assumes your values don't themselves contain pipes; if they do, pick another approach (or keep that data in JSON, where it belongs). I'd rather tell you this upfront than pretend the conversion is reversible in every case. Flat data round-trips perfectly. Nested data round-trips flattened.

The Excel semicolon problem nobody warns you about

You export a perfectly valid comma-separated file, send it to a colleague in Paris or Berlin, and they open it to find every row crammed into column A. Nothing is wrong with the file. Excel just reads the Windows regional settings, and in locales where the decimal separator is a comma (most of continental Europe), it expects semicolons between fields instead.

That's the whole reason the semicolon option exists in this tool. Working with French-locale Excel users? Export with semicolons and it opens clean, no import wizard needed. The tab option is the third escape hatch: tabs almost never appear inside data, so TSV sidesteps the quoting dance almost entirely. Less elegant, weirdly reliable.

Type inference is useful and slightly dangerous

CSV has no types. Everything is text. So when converting back to JSON, this tool can optionally guess: 36 becomes a number, true becomes a boolean, an empty cell becomes null. Most of the time that's exactly what you want, and it's what makes a flat round trip come back identical.

But guessing has teeth. A zip code like 00042 must not become 42, so the inference here refuses anything with a leading zero. Integers longer than 15 digits stay strings too, because JavaScript numbers would silently round them (ask anyone who's pushed Twitter IDs through JSON.parse). And there's no cure for ambiguity: if a cell literally contains the text true, the tool can't know whether you meant a boolean or a word. When the data is IDs, phone numbers or codes, turn inference off and cast types yourself downstream. When it's measurements and flags, leave it on and enjoy.

Frequently asked questions

Does this handle commas and line breaks inside fields?

Yes. The parser is a real state machine that reads the file character by character, so a quoted field can contain the delimiter, real line breaks, doubled quotes, even a trailing comma. That's the entire reason this tool exists. A split on commas can't do any of it.

Why does Excel open my CSV as one giant column?

Locale, almost every time. If the machine's region uses a comma as the decimal separator, Excel expects semicolons between fields and treats your commas as plain text. Re-export here with the semicolon delimiter and it opens clean. Or use Excel's import wizard and pick the delimiter by hand.

What happens to nested objects and arrays?

Nested objects become dot keys, so user.address.city turns into one column. Arrays get joined with a pipe. It's lossy by design: a spreadsheet is flat and your JSON isn't. Arrays of objects get each item stringified before joining, which is ugly but honest.

Will my zip codes lose their leading zeros?

Not here. Type inference deliberately refuses to convert anything with a leading zero, so 00042 stays a string. Excel is the one that mangles those, usually the moment you open the file. Integers longer than 15 digits also stay strings, because JavaScript would silently round them.

Is my data uploaded anywhere?

No. The whole conversion runs in your browser; you could go offline and it would still work. That said, don't make a habit of pasting customer data into random online tools. This one keeps it local, but the habit is the risky part.

Can I convert CSV back to the exact same JSON?

If the JSON was flat, yes. With type inference on, the round trip comes back identical, quoting included. If it had nested objects, the CSV side only knows dot keys, so you get flat objects named like user.city instead of the original nesting. The values themselves survive intact.