CSV / TSV ↔ JSON Converter

Features

• Both directions: CSV → JSON and JSON → CSV, detected automatically or set by hand
• Delimiter detection for comma, semicolon, tab and pipe — based on “makes every row the same width”, not on frequency
• Quoting, embedded newlines and `""` escapes follow RFC 4180, so the CSV opens correctly in Excel
• Strips the BOM Excel writes — otherwise the first key name hides an invisible character
• Numbers only when lossless: `007`, `1.50`, `1e5` and long IDs stay strings
• Headerless input becomes an array of arrays, rather than inventing keys like `"0"` and `"1"` that look like real field names
• Duplicate headers get a suffix (`id`, `id_2`), so later columns do not silently overwrite earlier ones
• Rows longer than the header keep their extra columns; shorter rows get empty strings
• JSON → CSV takes the union of all keys, so a field that first appears in a later row is not dropped
• Three directions: CSV → JSON, JSON → CSV and CSV → SQL (INSERT statements, optionally with CREATE TABLE)
• ⚠️ Table and column names in SQL output go through a whitelist before being emitted — anything else is double-quoted, single quotes in values are doubled, and no injection path is built
• ⚠️ The SQL type guess is only a guess, and shares its rules with CSV → JSON (`true` is a string in both)
• Nested objects and arrays are written into the cell as JSON text
• Syntax-highlighted output; JSON indent of 2 or 4 spaces, or a tab

How to use

1. Paste CSV / TSV or JSON — anything that parses as JSON is treated as JSON, the rest as CSV
2. Direction, delimiter and the presence of a header can all be set by hand
3. The result updates as you type; if the delimiter was misread, pick one manually
4. Copy the result

FAQ

Is the type in CSV → SQL a guess?

Yes, and the page says so. It looks only at what the values look like: all integers gives `INTEGER` (`BIGINT` past 32 bits), all decimals gives `NUMERIC`, anything else gives `TEXT`. It has no idea what the column means in your database — a column of phone numbers is all digits, but the correct type is `TEXT` (leading zeros, the `+` in a country code). So treat the `CREATE TABLE` as a starting point, adjust it to your actual semantics, and then use it.

Is the generated SQL safe to run?

The string-building side is written against injection: table and column names pass a whitelist first (letters or underscore to start, then letters, digits and underscores, and not a reserved word) and anything else is double-quoted; single quotes inside values are always doubled. Both are necessary — the CSV content comes from somewhere else, and one unescaped quote lets that row’s value close early and turns the rest into part of the statement. Whether the statement itself is valid is another matter: the types are guessed and the column names come from the header, so review it before running it.

Why did some numbers become strings and others not?

The default test is lossless round-tripping: a cell is converted only if turning it into a number and back gives the original string. `30` → 30 → `30`, so it converts. `007` → 7 → `7`, which differs, so it stays `"007"`. `1.50` likewise stays as written. Integers beyond 2^53 — a 20-digit order number, say — would lose digits, so they stay strings. You get real number types for the values where that is safe, and no irreversible changes where it is not. Pick “All as text” to disable inference entirely.

How is the delimiter decided?

It picks whichever of comma, semicolon, tab or pipe makes every row split into the same number of fields. Frequency alone would be fooled by the data: in a semicolon-separated file whose notes column contains commas, commas can easily outnumber semicolons, and counting would misread the whole table. If no candidate is consistent — which happens when the rows genuinely have different widths — it falls back to comma. If it guesses wrong, choose one manually; the control sits above the result.

Why did blank lines disappear?

Blank lines are skipped. They are common in hand-edited CSVs, and Excel and every other reader produces no data row from them; keeping them would add junk records like `{"id":"","name":""}` to the JSON. The cost is that in a single-column file a genuinely empty value is dropped too — for one-column data with blanks, add a placeholder column before converting.

What happens to nested objects and arrays?

They are written into the cell as JSON text — `{"a":{"x":1}}` becomes a single cell containing `{"x":1}`. CSV has rows and columns and nowhere to put nesting. The alternative is flattening into `a.x` style columns, which requires dots to be legal in column names and cannot be reversed. If the structure matters, keep the JSON and do not convert it to CSV.

Will Excel open the output correctly?

Yes. The JSON → CSV output uses CRLF line endings — what RFC 4180 specifies and the only form Excel accepts unconditionally — and any field containing a comma or a newline is quoted, so nothing shifts. The other direction is covered too: the BOM Excel writes at the start of a CSV is stripped, since leaving it in puts an invisible U+FEFF at the start of the first key, which prints exactly like `id` but never matches `obj.id`.