A CSV becomes JSON by turning every row into an object and every column heading into a key, so a file starting with id,name,city comes out as an array of objects with those three properties. Any converter does that much, including the one on this site, which parses the text in your browser and hands back the array. The work is in the disagreements between the two formats: CSV has no types, no nesting and no encoding declaration, and JSON needs all three settled before a single character can be written.
What the output actually looks like
Given this CSV:
id,name,city,joined
1,Ada,London,1843-01-01
2,Grace,New York,1944-07-02the JSON is an array of two objects:
[
{ "id": 1, "name": "Ada", "city": "London", "joined": "1843-01-01" },
{ "id": 2, "name": "Grace", "city": "New York", "joined": "1944-07-02" }
]That shape — an array of flat objects keyed by the header row — is what most APIs, database importers and JavaScript libraries expect. No converter can tell whether your first line is data or a header, so if the file has no header row you have to say so; the keys then become positional names like column_1. Nothing can invent meaningful names for columns nobody labelled.
Why you cannot just split on commas
The first CSV reader anyone writes is a split on commas inside a loop over lines. It works on the sample file and then quietly corrupts the real one, because three features of the format break it.
Quoted fields. "Lovelace, Ada" is one value. Split it on the comma and you get two, and every column to the right of it shifts by one for that row only — which is the worst kind of bug, because the file still loads.
Doubled quotes. Inside a quoted field, a literal double quote is written twice. "She said ""no""" is the single value She said "no". There is no backslash escaping in CSV; if you assumed there was, you are corrupting anything containing an inch mark.
Line breaks inside fields. A quoted field may contain newlines, which means a CSV row and a line of text are not the same thing. Reading the file line by line is already the bug, before you have parsed anything.
These rules come from RFC 4180, the 2005 memo that wrote down what everyone was already doing. It is informational rather than binding, which is why real files deviate from it: bare carriage returns, semicolon delimiters, trailing blank lines. A parser worth using tolerates all of that and still gets the three rules right, which takes a character-by-character state machine rather than a regular expression.
Why your whole CSV comes out as one row
A single unmatched double quote ruins everything after it. From that character on, the parser believes it is inside a quoted field, so commas and line breaks stop being separators and become ordinary text. The rows before the stray quote survive; the rest of the file collapses into one row holding one enormous value.
The usual culprit is a stray inch mark, a height written as 5"11 or a measurement like 24" wide that was never escaped. No tool can guess where the quote should have closed — search the input for a lone " and fix it there. If a converter reports far fewer rows than you pasted, this is the first thing to check.
Why leading zeros and long IDs disappear
Every field in a CSV is text. JSON distinguishes 42 from "42", so the converter must decide, field by field, and every decision it gets wrong is silent data loss. The classic casualties:
- Leading zeros. ZIP code
01234becomes1234. Product code007becomes7. - Trailing zeros. Price
1.50becomes1.5, which matters the moment it is printed back onto an invoice. - Phone numbers.
+44parses as the number 44 and the plus sign disappears. - Long identifiers. JSON numbers are IEEE 754 doubles in practice, so above 9007199254740991 an integer can no longer be trusted to survive exactly and comes back with its last digits changed. Card numbers, snowflake IDs and 19-digit order references all land here.
A safe rule exists and it is narrow: convert a field to a number only if printing that number returns exactly the original characters. 42 survives the test. 007, 1.50, +44, 1e3 and every oversized integer fail it and stay strings. That is the rule the converter here uses. Two side effects come with it and are worth knowing before you diff the output: true and false become booleans, and an empty cell becomes null rather than an empty string. If either matters, switch type conversion off and cast the columns yourself downstream — with it off, every cell that exists in the file comes out as the exact text it held.
Dates stay as strings, and that is the right answer
JSON has no date type. 03/04/2024 is 3 April in most of the world and 4 March in the United States, and nothing in the file tells you which. A converter that picks one is guessing on your behalf, and it will be wrong for some fraction of your rows without saying so. Keep dates as ISO-8601 strings — 2024-04-03 — and let whatever consumes the JSON decide what they mean.
What happens to rows that do not match the header
Real exports have ragged rows. The sensible handling is to keep them rather than reject the file: a short row gets null for the missing columns, a long one keeps the extras under positional keys. What matters is that the converter says it happened. Ragged rows almost always mean the file is damaged — a stray delimiter, a truncated download — so a count of how many were short or long is a diagnostic, not a footnote.
Can you get nested JSON out of a flat CSV?
Not from the file alone, and this is the limit that sends people hunting for a setting that does not exist. A CSV is a rectangle. If your column is named address.city, a straight conversion gives you a key with a dot in its name, not an address object containing a city. The dot means something to you and nothing to the file.
Some converters offer to read dotted names as paths. That is a convention, not a format, and it breaks the first time a legitimate column name contains a dot. If you need nested output, convert to flat JSON and reshape it in a few lines of code, rather than hoping a checkbox guessed your schema.
Why accented characters arrive as garbage
If José shows up as José, the damage happened before the conversion. That is UTF-8 bytes being read as Latin-1, and it was baked in when the file was saved or opened. Re-exporting as UTF-8 from the original source is the fix. Going the other way — decoding the mangled text back — sometimes works, but any character the wrong code page could not represent was already replaced with a question mark or a placeholder, and no amount of re-decoding brings those back. Start from the original file if you still have it.
One related detail: Excel's "CSV UTF-8" export writes a byte order mark at the start of the file. Unless something strips it, that invisible character glues itself to your first column name, and you spend twenty minutes wondering why data[0].id is undefined when the key is really \uFEFFid. The converter here removes a leading BOM before parsing, so this one does not reach your output — but a script you write yourself will not do it unless you ask. Anything that mangles text in ways you cannot see is worth knowing about in general, and the same category of problem shows up when an ampersand in your data meets HTML and comes out the other side as &.
What a round trip loses in each direction
Converting JSON back to CSV flattens everything: nested objects are collapsed into dotted columns, an array is squeezed into a single cell as JSON text, and every type becomes text again. So a CSV → JSON → CSV round trip will not give you back a byte-identical file, and a JSON → CSV → JSON round trip loses the types outright. If you need the reverse direction, the JSON to CSV converter handles the flattening, and what a nested structure costs you on the way down is worth reading before you commit to it as a pipeline step.
When to stop using a converter and write code
A browser tool is right for a one-off file, a sample you need to eyeball, or a paste from a spreadsheet. It stops being right at three points: files above a few megabytes, because everything is held in memory — the file picker here refuses anything over 5 MB rather than freezing your tab, though nothing stops you pasting that much text by hand; anything you will do more than twice, because a script you can rerun beats a tab you have to remember; and anything needing streaming, where rows are processed as they arrive.
Otherwise the check is always the same. Convert, then read the first object and the last one. Leading zeros intact, dates still strings, no key with a stray character in it, row count matching the spreadsheet. Thirty seconds, and it catches nearly every failure listed here.
The CSV to JSON converter here parses the text in your browser, so nothing is uploaded, and it reports the awkward cases out loud rather than swallowing them — ragged rows, duplicated header names, an unclosed quote. Type conversion follows the strict round-trip rule, so your ZIP codes keep their zeros unless you tell it otherwise.
If the mangled-text problem is the one that brought you here, HTML entities covers the other half of it: the same value meaning two different things depending on whether it is being stored or displayed, and which layer is supposed to do the escaping.
Frequently asked questions
How do I convert a CSV file to JSON?
Paste the CSV or load the file into a converter, confirm the first row is being treated as the header, and copy the JSON array it produces. Each row becomes an object and each column heading becomes a key. Browser-based converters do this without uploading the file anywhere.
Why did my leading zeros disappear when I converted CSV to JSON?
Because the converter decided the field was a number, and the number 01234 prints as 1234. Any ZIP code, product code or phone number with a leading zero or plus sign is affected. Either switch off automatic type conversion, or use a converter that only creates a number when it prints back identically to the original text.
Can I convert CSV to nested JSON?
Not directly. A CSV is a flat rectangle with no way to express a nested object, so a column called address.city becomes a key with a dot in its name rather than an address object. Convert to flat JSON first, then reshape it in code where the mapping rules are explicit.
Why is my whole CSV coming out as one row?
There is an unmatched double quote somewhere in the file. From that character onwards the parser thinks it is inside a quoted field, so commas and line breaks are treated as ordinary text and everything after it collapses into one enormous value. Search the input for a lone double quote, usually an inch mark like 5"11, and fix it there.
Does converting CSV to JSON online upload my file?
It depends on the site, and plenty of them do post your text to a server, where it lands in logs and backups you never see. Tools that parse in the browser never send the file at all, and say so. If the data is customer records or anything covered by a privacy agreement, check which kind you are using before pasting.
What is the difference between CSV and JSON?
CSV is a flat table where every value is text and structure is implied by position. JSON has types, nesting and arrays, and names every value explicitly. That is why CSV to JSON requires guessing types, and JSON to CSV requires throwing structure away.
Last updated September 19, 2026