Why your CSV has only one column
You open a CSV and every row is sitting in column A, commas and all. This is the single most reported CSV problem there is, and it has at least six different causes. The good news is that they are quick to tell apart, and each has a specific fix.
Work down the list in order. The first three account for most cases.
Cause 1: your list separator does not match the file
Symptom. The file is comma delimited, you can see the commas in column A, and Excel refuses to split on them.
Why. Double-clicking a CSV does not trigger delimiter detection in Excel. It uses the list separator from your operating system's regional settings. If your machine is set to a locale that uses the semicolon, a comma-delimited file has no separator Excel recognizes.
Fix. Import through Data, then From Text/CSV, where you can choose the delimiter. Or change the delimiter in the file once so it matches the machine that has to open it.
Fix it: convert between comma and semicolon →
Cause 2: there is prose above the table
Symptom. The first few rows are a company name, an address, an account number and a date range. Then the real header. Everything is in one column.
Why. Automatic delimiter detection samples the top of the file. The top of this file is not a table, so nothing scores well and the parser concludes that each line is one field. Bank statements, brokerage exports, ERP reports and anything with a letterhead behave this way.
Fix. Tell the parser how many rows to skip, or use a loader that finds the table itself. This case was common enough in real files that we built for it: before DuckDB's sniffer sees a CSV, our loader scans up to the first 5,000 lines of files under 8 MB, locates the region that actually holds a delimited table, and trims the prose above and below it. You get a notice saying how many lines were skipped, and you can turn it off if the guess was wrong.
Watch for a trailing block too. Disclaimers and totals below the table cause the same problem from the other end, and skipping leading rows alone will not fix it.
Fix it: load the file and let the table region be detected →
Cause 3: the delimiter is not what you assumed
Symptom. The values in column A are separated by pipes, tabs, carets or something else entirely.
Why. The file extension says CSV and the contents say otherwise. Banking and telecom exports frequently use pipes. Scientific tooling uses tabs. Some legacy healthcare formats use carets. The extension is a convention, not a declaration.
Fix. Look at the first line and read what is between the column names, then set that as the delimiter. Tabs are the tricky one because they are invisible; if the values look aligned in a text editor, suspect tabs.
Fix it: the delimiter guide, including how to identify one from the terminal →
Cause 4: every line is wrapped in quotes
Symptom. The file looks like this:
"id,name,city"
"1,Ann Lee,Tokyo"
"2,Jon Roy,Berlin"
Why. Something quoted the entire line rather than each field. The parser is behaving correctly: each line is a single quoted field that happens to contain commas. This usually comes from a script that wrapped each output line in quotes to be safe, or from a system that exported a text column which itself contained a CSV.
Fix. Strip the outer quotes and re-parse. If this arrives regularly, fix the producing script; a CSV writer quotes fields, never lines.
Fix it: re-parse the stripped text into a proper table →
Cause 5: the line endings are not recognized
Symptom. Not just one column, but one row. The whole file is a single enormous cell.
Why. Lone carriage returns, which classic Mac software and some mainframe exports produce. A parser that splits on line feed finds none and reads the file as one line. An unterminated quote produces the same shape from a different direction: everything after the stray quote is inside one field.
Fix. Normalize the line endings, or find the row where quoting breaks. Our loader treats this shape as a failure rather than a result: if the parse yields one or two rows out of a file with many physical lines, or a single column whose name contains the delimiter, it retries with more forgiving options instead of handing you the garbage. A parser that reports success on nonsense is worse than one that fails.
Fix it: the line endings guide →
Cause 6: it really is one column
Symptom. One value per line and no delimiters anywhere.
Why. Because it is a list. An export of email addresses, a set of IDs to look up, a column pasted out of a spreadsheet. This is a perfectly valid CSV.
Fix. Nothing to fix. If you expected more columns, the export configuration is where to look, not the file. And if the single column contains values that need splitting, like a full name or an address, that is a transformation rather than a parse.
Fix it: split a single column into several by a separator →
Check what is really in the file
A minute of looking beats an hour of guessing. Run these three in order.
# 1. What do the first lines look like?
head -5 yourfile.csv
# 2. Which candidate separator appears most in the header?
head -1 yourfile.csv | tr -cd ',' | wc -c
head -1 yourfile.csv | tr -cd ';' | wc -c
head -1 yourfile.csv | tr -cd '|' | wc -c
# 3. Any carriage returns, and are they paired with line feeds?
head -c 200 yourfile.csv | od -c | head
Line 1 identifies a preamble and quoted lines instantly. Line 2 identifies the delimiter. Line 3 identifies the line ending problem. Between them you will have named the cause, and the section above tells you what to do about it.
If you would rather not use a terminal, the validator answers the same three questions from the browser and adds a list of rows whose field count disagrees with the header, which is where the remaining surprises usually live.