Text to CSV Converter

How it works

• CSV is parsed to RFC 4180: a quoted field can contain commas, line breaks and doubled quotes, and all three are handled rather than splitting naively on commas. This is the step most free converters get wrong.
• On the way out, any field containing the delimiter, a quote, a newline or leading whitespace is quoted and its internal quotes doubled, so the output survives a round trip.
• The delimiter is detected from the first line — comma, tab, semicolon or pipe — and the tool reports which one it used instead of assuming.
• Type detection turns bare numbers, booleans and nulls into real JSON types; turn it off to keep every value a string, which is what you want for IDs with leading zeros.

Use cases

The quoting rules most CSV converters get wrong

CSV looks trivial and is not. The format described by RFC 4180 allows a field to be wrapped in double quotes, and a quoted field may contain the delimiter, a line break, or a double quote written twice. So a,"b,c",d is three fields and not four, and "say ""hi""" is one field containing say "hi". Any parser that splits a line on commas is wrong the first time a value contains a comma, which for real data is immediately: addresses, product names and free-text notes all contain commas.

The multi-line case is the one that causes silent damage. If a quoted field contains a newline, a parser that splits the file into lines before parsing fields has already destroyed the record, and the error surfaces as a row with the wrong number of columns somewhere else entirely. This is the single most common reason a CSV that opens correctly in a spreadsheet breaks in a script.

Writing is the mirror image. A field needs quoting if it contains the delimiter, a quote, a newline, or leading or trailing whitespace that must be preserved — and any quote inside it must be doubled. Getting both halves right is what lets output from this tool be fed straight back into it without loss.

Delimiters, locales, and why Excel opens everything in column A

Despite the name, comma-separated values are not always comma-separated. In locales that use a comma as the decimal separator, Excel writes and expects a semicolon, and opening a comma-delimited file there puts every row into a single cell. The reverse happens just as often when a file produced in Germany is opened in the United States.

There is no marker in the file to say which was used, so the delimiter has to be detected or declared. This tool detects it from the first line and tells you which one it chose rather than assuming, because a silent wrong guess produces plausible-looking nonsense.

When a file has to open correctly everywhere, tab-separated values are the pragmatic answer: tabs almost never appear inside data, and every spreadsheet in every locale reads them the same way. Export as TSV and the locale problem disappears.

Type detection, and when to turn it off

Converting to JSON raises a question CSV never had to answer: is the value 42 a number or the string "42"? CSV has no types at all, so something has to decide. With detection on, bare integers and decimals become JSON numbers, true and false become booleans, and empty fields become null — which is almost always what you want for data that will be computed on.

It is the wrong default for identifiers. A zip code of 02134, a product code of 00731, or a phone number beginning with a plus will all be damaged by being read as numbers: the leading zeros disappear and cannot be recovered. Long numeric IDs have a second problem, because beyond about 15 digits a JSON number loses precision in most parsers — an identifier can come out one digit different from what went in, which is far worse than an obvious failure.

The rule is simple enough to apply without thinking: if you would ever do arithmetic on the column, let it be a number. If it is a label that happens to be made of digits, keep it a string.

FAQ