How to Convert CSV to JSON Without Losing Data

The job in plain words

You have a CSV file from a spreadsheet, an export, an API response. You need it as JSON for a database, a web app, an LLM prompt. The conversion sounds simple. Half the time it works on the first try. The other half you lose data without noticing.

This is the checklist that catches the silent failures before they become a production bug.

Step 1: Confirm the delimiter

Open the file in a plain text editor. Look at the first line. Whatever sits between the values is your delimiter.

Most files use a comma. Spreadsheets exported from Spanish, French or German Excel often use a semicolon. Older Unix tools sometimes use a tab. The file extension is .csv regardless.

If your converter parses everything as a single column, the delimiter is wrong. Tell the tool which one to use, do not guess.

Step 2: Check the encoding

The most common silent bug is opening a UTF-8 file as Windows-1252 or vice versa. Accents come out as garbage characters (pingüino becomes pingüino).

Modern converters detect UTF-8 automatically most of the time. When they cannot, they fall back to Latin-1 and the file looks half right. If your data has accents and they look wrong, the encoding is wrong.

The CSV to JSON converter on AldeaCode handles UTF-8, Latin-1 and Windows-1252 transparently. If your file uses something else (rare in 2026), open it in a real editor and save it as UTF-8 first.

Step 3: Watch for the BOM

The Byte Order Mark is three invisible bytes some Microsoft tools add to the start of a UTF-8 file. They tell the reader “this is UTF-8”. Most parsers handle the BOM correctly.

Some parsers do not, and the BOM ends up as part of the first column header. Your JSON ends up with a key called Name instead of Name, and any code looking up Name finds nothing.

If your first column key looks weird and you cannot find it by name in the resulting JSON, suspect the BOM. The fix is to strip it before parsing, or use a converter that knows about it.

Step 4: Decide what your headers are

CSV usually puts column names in the first row. Sometimes it does not. Sometimes the first row is metadata and the second row is the headers. Sometimes there are no headers at all and you have to invent them.

Before converting, decide:

• Does the file have a header row? Yes / no.
• If yes, are the headers clean (product_name) or messy with spaces and case (Product Name )?
• Do you want the JSON keys to match the headers exactly, or normalize them (lowercase, snake case, no trailing spaces)?

A good converter lets you control all three. A bad one always uses the first row as headers, and you find out at hour two that your spreadsheet had a title row that pushed everything down.

Step 5: Quote handling

If a value contains the delimiter, the standard says wrap it in quotes. So Hello, world becomes "Hello, world".

The trap is that quotes inside the value can be encoded two different ways. Excel doubles them: "He said ""hi""". Most Unix tools accept both doubled and backslash escaped: "He said \"hi\"".

If your converter chokes on a specific row, the row probably has a quoted value with internal quotes done in a style your parser does not expect. Try the opposite quoting style.

Step 6: Decide what JSON shape you want

The default conversion is an array of objects. Each row becomes an object with keys from the headers.

[
  { "id": "1", "name": "Maria", "city": "Madrid" },
  { "id": "2", "name": "Carlos", "city": "Lima" }
]

Other shapes are useful in some cases:

• A single object keyed by id, when you need fast lookups ({ "1": { "name": "Maria"... }, ... }).
• An array of arrays, when you do not have headers ([ ["1", "Maria", "Madrid"], ... ]).
• A streaming format (one JSON object per line), when the data is too big to fit in memory.

The CSV to JSON converter lets you pick the shape directly. The JSON formatter is useful afterward to validate the result.

Step 7: Type inference, the dangerous one

Some converters automatically turn "1" into 1, "true" into true, "2026-05-01" into a date. This sounds helpful and is often a disaster.

Phone numbers starting with 0 lose the leading zero. ZIP codes from 00214 become 214. Booleans like "yes" and "no" get coerced to strings only sometimes. Dates parse as different things depending on the locale.

The safe default is “everything stays a string”. Then you cast to the right type in the consuming code, where you have schema awareness. If you must infer, infer per column with explicit rules, not globally.

A 30 second checklist

Before treating the conversion as done:

1. Same number of rows in CSV and JSON?
2. Same number of fields per row, no truncated lines?
3. Accented characters look right?
4. First column key has a normal name, not garbled bytes at the start?
5. Numbers are numbers and strings are strings, in the columns where you expect each?

The CSV to JSON converter, the JSON formatter, the text counter and the find and replace on AldeaCode all run in your browser. Data never leaves your tab. Five minutes with this checklist beats five hours debugging a broken import.