The quoting rules that trip up naive parsers
Splitting on commas works until a field contains one. RFC 4180 wraps such fields in quotes and doubles any quote inside them, so "Smith, John" is one field and "He said ""hi""" is another. A line break inside quotes is part of the value, not the end of the row — which is why address columns break so many imports.
All three are handled here. If a file still parses oddly, the delimiter is usually the culprit: European exports commonly use semicolons, because the comma is their decimal separator.
Headers and types
With the header option on you get an array of objects keyed by the first row. Two columns with the same name would otherwise silently overwrite each other, so the second is renamed rather than lost.
CSV has no types — everything is text. Numeric conversion is optional here for that reason: turning 007 into 7 destroys postcodes and part numbers, which is the most common way a CSV import quietly corrupts data.
Frequently asked questions
Why is my data shifting into the wrong columns?
Almost always an unquoted comma inside a field, or the wrong delimiter. European exports often use semicolons. Try switching the delimiter before anything else.
Should I convert numbers automatically?
Only if every numeric column is genuinely a number. Anything with a leading zero — postcodes, part numbers, phone numbers — loses meaning when 007 becomes 7.
What happens to duplicate column names?
They are kept apart rather than overwriting each other, so no data is silently dropped.
Is my file uploaded?
No — it is parsed in your browser, which matters when the CSV is an export of customer or financial records.
Something wrong with this tool, or an idea for it? Tell us