CSV to TXT Converter

Renaming the file is not converting it

Changing .csv to .txt gives you exactly the same commas and quotation marks under a different name. If what you wanted was something readable, or something a different program will take, the extension was never the problem.

So this re-writes the data rather than relabelling it, and offers three layouts because "CSV to TXT" is asked for three different reasons.

The three layouts

Delimiter keeps the table shape and swaps the separator — tab, semicolon, pipe or space. This is the one that will still open in a spreadsheet, and it is what you want when another program is fussy about commas. If you specifically need a .tsv file rather than a renamed .txt, the CSV to TSV converter does the same tab swap with a file extension and MIME type that match.

Aligned columns pads every column to its widest value so the table lines up when read in a fixed-width font. That turns an unreadable run of commas into something you can scan in a terminal, paste into an email, or drop into a plain-text document. It is for people rather than for parsers, and it will not import cleanly anywhere.

One field per line is for wide tables. A row with twenty columns is unreadable on a single line no matter what separates it, so each field goes on its own line with its column name in front and a blank line between records. Turn off the header option if your file has no header row.

What each layout looks like

Starting from this small CSV — three columns, one name containing a comma so it needed quoting:

id,name,city
1,"Smith, John",Leeds
2,Ada Lovelace,London
3,Grace Hopper,New York

The delimiter layout with tabs turns every comma between fields into a tab and leaves the data alone. Tabs are shown here as → so you can see where they land:

id→name→city
1→Smith, John→Leeds
2→Ada Lovelace→London
3→Grace Hopper→New York

Still one row per record, still machine-readable, and the comma that used to sit inside quotes in "Smith, John" is now harmless — it is just a character in the name, because the separator is a tab rather than a comma.

The aligned layout pads every column to its widest value:

id  name          city
1   Smith, John   Leeds
2   Ada Lovelace  London
3   Grace Hopper  New York

name is padded to the width of its longest value, Ada Lovelace, and the last column is never padded — trailing spaces at the end of a line are invisible and only cause trouble. In a fixed-width font that lines up into a table you can read; in a proportional font the columns will not line up, which is worth knowing before pasting it into a word processor.

The one field per line layout, with the header used as labels:

id: 1
name: Smith, John
city: Leeds

id: 2
name: Ada Lovelace
city: London

id: 3
name: Grace Hopper
city: New York

Three lines per record instead of one, with a blank line between records, and the header row itself is not printed as data — it only supplies the labels. Turn off the header option and the labels disappear, leaving just the values.

It still parses properly

Whichever layout you pick, the input is read with a real parser rather than split on commas. A value like "Smith, John" stays one field, a doubled quote inside a quoted value becomes one quote, and a newline inside quotes is part of the value rather than the end of the row.

The delimiter of your input is detected from the data — semicolons, tabs and pipes are all recognised alongside commas — which matters because European Excel exports use semicolons and a fair number of files ending in .csv are tab-separated anyway. Detection counts each candidate character outside quotes across the first lines of the file and picks whichever one shows up the same number of times on every line; a character that appears seven times on one line and never on the next is prose, not a separator, and is ruled out.

A quoted value can contain a newline, and that newline stays inside the field rather than ending the row — a multi-line note or address in one cell is read as one cell, not as extra rows. A doubled quote inside a quoted value, written "" in the source CSV, becomes a single literal quote in the output. And a stray quote in the middle of an unquoted field is left as-is rather than treated as the start of a quoted run, which matches what a spreadsheet does when it writes CSV.

Ragged rows and missing cells

Not every CSV export has the same number of columns on every line. The aligned layout pads short rows up to the width of the widest one, using ECSCsv.rectangular(), so a ragged file still lines up instead of the columns drifting sideways after the first short row. The delimiter layout does not pad — it writes exactly the cells each row has, which is the correct behaviour for a file meant to be read back by another program rather than looked at.

Turning on "Remove completely empty rows" drops any row where every cell is blank or whitespace, which is what a trailing blank line at the end of an exported file usually produces. A row with some empty cells and some filled ones is kept either way; only a row that is empty all the way across is removed.

Where your data goes

Nowhere. Parsing, formatting and file reading all happen in your browser, and this page has no upload endpoint to send anything to. A file you drop is read on your own device and its text goes straight into the box; nothing is logged, and there is no account.

A dropped file is capped at ten megabytes and the parser at around two million cells. Past that, a browser tab is genuinely the wrong tool for the job.

If your contacts are the CSV

A contact list turned into aligned text is easy to read but nothing will import it. For that, use the CSV to vCard converter instead, which maps your columns to name, email, phone and address fields and builds a .vcf file your phone can add directly.