Online Tool Store
CSV Column Extractor
Extracts and reorders CSV columns in your browser. Detects the delimiter by counting outside quoted fields and scoring row consistency, handles quoted values containing commas, and reports ragged rows and duplicate headers instead of padding them silently.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Columns to keep
Click to toggle. Output follows the order you select them in.
Parsed in this page, so nothing is uploaded — which matters because the CSVs people extract columns from are usually exports full of names, addresses and email addresses.
How to use it
- Paste or open a CSV — the delimiter is detected and reported.
- Click the columns you want, in the order you want them.
- Read any warnings; ragged rows usually mean something is wrong upstream.
- Pick an output format and copy or download.
Detecting the delimiter properly
The obvious approach is to count commas, semicolons and tabs and pick whichever appears most. That fails on a very common file: a semicolon-delimited export from European software, where a description or address column contains plenty of commas.
id;desc
1;"one, two, three, four"
2;"five, six, seven"
raw counts commas 5, semicolons 3 → picks comma, wrongly
outside quotes commas 0, semicolons 3 → picks semicolon
So the counting here ignores anything inside quotes, and then scores each candidate by how consistent its per-row count is — a real delimiter produces the same number of fields on every line, while a stray character does not. That combination correctly identifies comma, semicolon, tab and pipe files, and recognises a single-column file as having no delimiter at all rather than inventing one.
Ragged rows are a warning, not a shrug
When a row has a different number of fields from the header, most tools quietly pad or truncate it and move on. That hides the single most damaging kind of CSV corruption, because a row that is one field short does not just lose a value — every field after the gap has shifted into the wrong column.
header id,name,email 3 fields
line 3 2,Grace 2 fields short by 1
line 4 3,Alan,a@x.com,extra 4 fields long by 1
Extraction still works — a missing column yields an empty value rather than an error — but the affected line numbers are reported so you can check whether the file is genuinely sparse or whether an unbalanced quote higher up has swallowed a line break. Duplicate column names get flagged for the same reason: selection here is by position so both remain reachable, but a tool that matches by name would silently pick one and ignore the other.
Quoting on the way out
Extracting columns means writing a new file, and that file has to survive being parsed again. A value is quoted when it contains the delimiter, a quote character, a line break, or leading or trailing whitespace — and left bare otherwise, which keeps the output readable instead of quoting everything defensively.
Embedded quotes are doubled, which is the CSV convention rather than a backslash escape. So a name held as
Smith, John comes out as
"Smith, John" and survives the round trip intact.
Choosing an output format
CSV is the right default, because it is the only one of these with defined escaping. Tab separated is convenient for pasting into a spreadsheet but has no agreed way to represent a value containing a tab, so it is a poor choice for storage. JSON gives you an array of objects keyed by column name, which is usually what you want if the next step is code. Plain list is for pasting into something else entirely.
The SQL IN clause deserves its warning. It doubles quotes so the literal is valid, and that is not injection protection — it is a convenience for pasting a list of identifiers you already trust into a query you are writing yourself. It uses only the first selected column, since an IN clause takes a single list.
FAQ
How does it know which character separates my columns?
It counts each candidate — comma, semicolon, tab and pipe — but only outside quoted fields, and then scores them on how consistent the count is from row to row rather than on how often they appear. That matters for European exports, which use semicolons and are full of commas inside their text columns: counting raw frequency picks the comma and shreds the file. You can always override the detection, and the tool tells you what it chose and how consistent it was.
Why is it warning me that my rows are different widths?
Because that is almost always a real problem rather than a quirk. A row with fewer fields than the header usually means the file was split on the wrong character or a quote is unbalanced somewhere above it, which silently shifts every subsequent field into the wrong column. Missing values do come through as empty rather than breaking, but the mismatch is reported per line so you can go and look.
Does the output order follow my file or my selection?
Your selection. The columns are numbered as you click them, so you can reorder as well as filter — click email then name and that is the order you get. Deselect and reselect a column to move it to the end.
Why does a value come back wrapped in quotes?
Because it contains the delimiter, a quote character, a line break, or leading or trailing spaces, and without quoting it would be misread when the file is parsed again. Values that do not need quoting are left bare, which is what the CSV convention expects and what makes the output readable.
Is the SQL output safe to use with user data?
No. It doubles quote characters so the literal is syntactically valid, which is not the same as being safe — a value in a numeric position has no quote to double, and the whole approach is the wrong tool for untrusted input. Use it to paste a list of IDs you already have into a query you are writing by hand, and use parameterised queries for anything else.
Why prefer CSV over tab-separated output?
Because tab-separated has no agreed escaping rules. If a value contains a tab or a line break there is no standard way to represent it, so the file becomes ambiguous — whereas CSV has a defined mechanism for exactly that. TSV is convenient for pasting into a spreadsheet and a poor choice for storing anything.
How we compare
| Feature | Online Tool Store | A spreadsheet | cut or awk |
|---|---|---|---|
| Data never leaves your device | ✓ | Depends | ✓ |
| Handles quoted fields containing the delimiter | ✓ | ✓ | ✗ |
| Reports ragged rows and duplicate headers | ✓ | ✗ | ✗ |
| Reorders columns by selection order | ✓ | By hand | ✓ |
| Detects the delimiter, ignoring quotes | ✓ | On import | ✗ |
| Files too large for a browser tab | ✗ | Row limits | ✓ |
| Filtering, sorting and formulas | ✗ | ✓ | With effort |
The advantage over cut is that quoted fields containing the delimiter
are handled correctly, which is where a one-line shell command usually goes wrong. The advantage over a spreadsheet is that it
will not reformat your data on the way in — no dates turned into serial numbers, no long identifiers rendered in scientific
notation. For a file too big to paste, use the command line and accept the quoting caveat.