Spreadsheets speak CSV. APIs speak JSON. So sooner or later you paste an export from Excel, Google Sheets or Amazon Seller Central into a converter and expect a clean array of objects.
Most of the time you get one. The dangerous cases are the ones that look fine: the JSON is valid, the row count matches, nothing throws an error — and yet a zip code lost its leading zero, or one customer's name got split across two fields. Nobody notices until the shipping labels print wrong.
Here are the six failures that actually happen in practice, how to recognise each one, and how to convert without them.
1. The 30-second version
If you just need the output: open the CSV to JSON converter, paste your data with a header row on top, and click convert.
name,age,city Alice,28,NYC Bob,32,LA
becomes:
[
{ "name": "Alice", "age": "28", "city": "NYC" },
{ "name": "Bob", "age": "32", "city": "LA" }
]
The header row becomes the keys; every following row becomes one object. Everything below is about the rows that don't behave this politely.
2. Pitfall: a comma inside a field splits your row
CSV separates columns with commas, so what happens when the data itself contains one? Smith, John in a name column, or Blue, Large, 2-Pack in a product title, turns one column into two. Every column after it shifts left, and the last one falls off the end.
The fix is part of the format: wrap the field in double quotes.
id,customer,total 1,"Smith, John",29.99
A parser that follows RFC 4180 — the informal CSV standard — tracks whether it is currently inside quotes and ignores separators while it is. Need a literal double quote inside the text? Write it twice: "6"" screen" yields 6" screen. Excel and Sheets do this quoting automatically on export, so the damage usually happens when a CSV is hand-edited or stitched together by a script.
How to spot it: compare the number of keys across objects, or scan for a value that obviously belongs to the next column.
3. Pitfall: leading zeros vanish
This is the most expensive one, because the output looks perfectly reasonable. A zip code 07030 comes out as 7030. A SKU 0012345 becomes 12345. A phone number starting with a country prefix loses its zero.
The cause: many converters try to be clever and infer types. A column that looks numeric gets cast to a JSON number — and a number has no concept of a leading zero, so it is gone the instant the cast happens. The same logic mangles long order IDs, which lose precision past 15-16 digits, and values like 1E5 or +1.0.
The rule worth remembering: if you never do arithmetic on it, it is not a number — it is an identifier, and identifiers belong in strings. Zip codes, SKUs, ASINs, order numbers, phone numbers and version strings all qualify.
Our CSV to JSON tool deliberately keeps every value as a string for exactly this reason. If you genuinely need numeric types, cast the specific fields you care about afterwards — that is a two-line change in your code, whereas recovering destroyed zip codes means re-exporting the whole file.
4. Pitfall: your CSV isn't comma-separated at all
Open a CSV exported by Excel on a European locale and you may find semicolons instead of commas. The reason is arithmetic: in locales where the decimal separator is a comma (29,99), the comma can't also separate columns, so Excel switches to ;.
Feed that to a comma parser and you get a single column whose name is the entire header row — an unmistakable symptom. Two ways out: re-export using comma separation (in Excel, "CSV UTF-8" rather than the locale default), or find-and-replace ; with , in a text editor first — but only if your data contains no semicolons of its own. Tab-separated exports have the same story.
5. Pitfall: line breaks inside a cell
Multi-line addresses and product descriptions frequently contain a newline. The CSV standard allows it as long as the field is quoted, but many lightweight parsers — including simple ones that split the file line by line — will read that single record as two broken rows.
If a converter gives you more rows than your spreadsheet has, this is almost always why. The quickest workaround is to flatten the offending column before exporting: in Excel, =SUBSTITUTE(A2, CHAR(10), " ") replaces in-cell line breaks with a space. Do this on a copy, not your source of truth.
6. Pitfall: the invisible character at the start of the file
You convert, then your code reads row.name and gets undefined — even though the JSON clearly shows a name key. Copy that key and inspect it: the real key is \uFEFFname.
That prefix is a byte order mark, an invisible character Excel writes at the start of UTF-8 files so it can recognise the encoding later. It silently becomes part of your first column name. Fix it by saving as "UTF-8 without BOM" in an editor such as VS Code or Notepad++, or by using a parser that strips it. It is worth knowing about simply because the symptom — one key that looks identical to the one you typed but doesn't match — is so baffling the first time.
7. Pitfall: the data you just uploaded to a stranger
The five problems above damage your data. This one exposes it.
An order export is not neutral data. It contains buyer names, shipping addresses, emails, and sometimes partial payment details. A back-office CSV may hold employee salaries or internal pricing. When you paste that into a converter that processes on the server, you have transmitted personal data to a third party you have never audited — a genuine problem under GDPR, and an unforced risk regardless.
This is not hypothetical. In late 2025, security researchers at watchTowr Labs found that popular online formatting sites had stored roughly 80,000 user-submitted documents behind public links — around 5 GB of data including API keys, database passwords and SSH private keys, all pasted in by people who assumed the page was a scratchpad.
The defence is simple: prefer converters that run client-side. Everything on Jisubao — the CSV to JSON converter, the JSON formatter, the password generator — executes as JavaScript inside your own browser. Your rows are never sent anywhere, which you can verify yourself: open DevTools, switch to the Network tab, convert, and confirm no request is made. Better still, load the page and then go offline — if it still works, the data isn't going anywhere.
8. A 60-second checklist
- Does row one contain real headers, not a title or a blank line?
- Are fields containing commas, quotes or newlines wrapped in double quotes?
- Is the delimiter actually a comma, not a semicolon or tab?
- Do identifier columns (zip, SKU, ASIN, phone) still show their leading zeros in the output?
- Does the output row count match the spreadsheet?
- Does the first key match what you expect, character for character?
- Does the file contain personal data — and if so, is the tool running locally?
9. FAQ
Q: Should numbers be strings in JSON? — For anything you will calculate with (price, quantity, weight), use real numbers. For anything that merely identifies something, use a string. When in doubt, keep it a string: converting a string to a number later is trivial, while recovering a mangled identifier is not.
Q: Can I convert JSON back to CSV? — Yes, provided every object shares the same keys. Uneven objects need a decision about which columns win, which is why one-directional exports are the usual pattern.
Q: Is there a size limit? — A browser-based converter is bound by your device's memory rather than an upload cap. Tens of thousands of rows are fine; for multi-hundred-megabyte files, use a streaming parser in a script instead.
Q: My JSON output looks cramped — can I make it readable? — Paste the result into the JSON formatter to indent and validate it, or the text diff tool to compare two exports and see exactly which rows changed.
CSV survives because it is simple enough for anything to write. That same simplicity means the format carries no schema, no types and no encoding declaration — every one of those has to be inferred, and every inference is a chance to get it wrong. Knowing where the guesses happen is most of the battle. 👉 Convert your file now with the free CSV to JSON tool.