· 6 min read
Converting CSV to JSON is easy for the part everyone thinks about, the header row and the delimiter, and genuinely ambiguous for the part that actually matters: every CSV value is plain text, so the converter has to decide whether "42" is a number, whether "true" is a boolean, and whether a header like address.city means the value belongs inside a nested address object. Get those three decisions right and the rest is mechanical.
TL;DR: a CSV to JSON converter turns the header row into keys and each following row into an object. The hard part is typing, since CSV has no types of its own, and reconstructing nesting from dotted or bracketed header names. Check a row you already know the answer for before trusting the output.
The header row supplies the keys, in order. Every row after it becomes one object, with each cell matched to the header in the same column. The output is an array of objects, one per data row. That part is unambiguous as long as every row has the same number of cells as the header.
CSV has no type system. Every cell is a string until something decides otherwise, and that something is a set of heuristics: a cell that looks like a number gets parsed as one, "true" and "false" become booleans, and everything else stays a string. Those heuristics are convenient and occasionally wrong, and the wrong cases are predictable rather than random.
| CSV cell | Naive inference | What it usually should be |
|---|---|---|
| 42 | number | number, this one is fine |
| 007 | number 7 | string, a code that lost its leading zero |
| +1 555 0100 | string | string, correct because of the punctuation |
| true | boolean true | boolean, usually correct |
| empty string or null | depends on whether the source distinguishes missing from blank | |
| 2026-09-26 | string | string, JSON has no native date type |
Leading zeros are the classic casualty. An account number, a zip code or a product code that happens to look numeric gets silently reinterpreted as an integer, and the zero is gone before you notice. Force those columns to stay strings rather than trusting automatic type detection.
Flat CSV headers can encode structure through convention. A dot in a header name, such as address.city, is a common signal to nest the value inside an address object with a city key instead of a flat address.city key. Square brackets in a header, such as tags[0], signal an array position. Neither convention is universal, so the safe habit is to look at the output once and confirm it matches what you expected, especially the first time you use a given converter on a given file.
Two columns with the same header collide, and one silently overwrites the other unless the converter renames or refuses. A row with fewer cells than the header row is missing trailing values, and how those are represented, an empty string, a null, or the key left out entirely, differs by tool. A row with more cells than the header has nowhere to put the extra ones and they are usually dropped. All three are worth checking on a real file rather than assumed.
The files people convert are usually exports from a real system: a customer list, an order export, an inventory sheet. That is personal and business data, not a sample file. Converting it with a tool that parses the CSV in your own browser tab means the rows never leave your machine as a request to someone else's server. Load the page, disconnect from the internet, and a browser-side converter keeps working; that is the practical way to check, rather than trusting a privacy policy.
Try it or go deeper
No. Type inference and how headers map to nesting both depend on the converter's rules, so the same file can produce different JSON in two different tools. Check a row you know the answer for.
It depends on the converter: some emit an empty string, some emit null, and some omit the key. If the distinction between missing and blank matters to you downstream, verify which one your tool chose.
Yes, if the converter supports dotted header names. A header like address.city produces a nested address object with a city key rather than a flat key with a dot in it.
The converter treated the cell as a number, and numbers do not keep leading zeros. Columns holding codes rather than quantities, such as zip codes or account numbers, should be forced to stay strings.
Not with a browser-side tool. The file is parsed by the JavaScript already running in your tab, which you can confirm by disconnecting from the internet and trying it again.