Why does my CSV import into a single column?

The file almost certainly uses a different delimiter than the importer expects — European Excel exports use semicolons instead of commas. A good importer sniffs the delimiter across several lines instead of assuming commas; otherwise, re-export with commas or configure the delimiter.

Why are my CSV rows merged or split in the wrong place?

Usually quoting: a field contains a comma or a line break and isn't properly quoted, or a stray quote character opens a quoted section that swallows following rows. Old Mac-style line endings (bare CR) also glue files into one row on naive parsers.

Why did the importer use my data as column headers?

The header row wasn't row one (title lines, export banners) or contained duplicate names, so header detection picked the wrong row. Look for an importer that scores candidate header rows and lets you override the choice.

CSV not importing correctly? The five real causes

When a CSV “doesn’t import correctly” — wrong columns, merged rows, one giant column, garbled characters — it’s almost always one of five causes. In the order we actually see them in the wild:

1. The delimiter isn’t a comma

European Excel exports use ;. Some tools emit tabs or pipes. A parser that assumes commas turns the file into one column — and some importers then happily “map” that single column. Fix: re-export with commas, or use an importer that sniffs the delimiter over several lines (and honors Excel’s sep=; hint line) instead of assuming.

2. Quoting gone wrong

A field containing a comma or newline must be quoted; a stray " mid-field can swallow every following row into one cell on strict parsers. Fix: quote fields that contain the delimiter; prefer an importer whose parser treats mid-field quotes as literal text instead of letting them derail the file.

3. The header row isn’t row one

Title lines (“Contact export — March”), blank first rows, or duplicated column names make naive header detection grab a data row as headers — then every column is named by your first customer’s data. Fix: delete preamble rows, or use an importer that scores header candidates and lets you pick the row explicitly.

4. The encoding isn’t what the importer assumed

Ã¼ where ü should be, ��, or Chinese-looking pairs from an Excel “Unicode Text” export (UTF-16). Full guide: CSV encoding & UTF-8 problems.

5. Excel’s locale rewrote your values

1,5 vs 1.5, 03/04/2026 meaning March or April depending on locale, leading zeros stripped from postal codes and phone numbers. Fix: import columns as text and convert deliberately during validation — never let the spreadsheet guess first.

How Mildport handles these

Mildport’s parser was hardened against exactly this list (every case above ships as a regression test): multi-line delimiter sniffing with sep= support, field-start-only quoting, bare-CR line endings, scored header detection with manual override, BOM/UTF-16/ windows-1252 detection, and typed columns so locale damage gets caught in review — with plain-language cleanup for what’s left.

See it on your own broken file: the playground runs in-browser, no signup — bring the CSV that won’t import.