Why did my postcode 01234 stay a string?

Because a leading zero is meaningful. Converting it to a number would silently give 1234, so any value starting with a zero is kept as text — postcodes, product codes and phone numbers survive intact.

Why is my row count an error instead of a warning?

Because a row that does not match its header is ambiguous: the tool cannot know whether a field was dropped or an extra delimiter slipped in. The message tells you how many fields were expected and how many were parsed, so you can find the line.

How do I keep everything as text?

Turn off **Detect types** above the editor. Every value then comes out quoted, which is what you want when the JSON is going straight into a system that does its own parsing.

CSV to JSON — Numbers Arrive as Numbers

Turn a CSV table into an array of JSON objects keyed by the header row. Numbers and booleans come out typed, ready to sum or compare in code.

Instant Private Zero cookies

Indentation

Delimiter

Swap: JSON → CSV

CSV input

JSON output

What this tool does

The header row becomes the keys, and each following row becomes one object in an array. Values are typed rather than quoted blindly: 30 comes out as the number 30, true as the boolean.

The delimiter is detected from the file, so a European export separated by semicolons works without changing anything.

What type detection touches, and what it leaves alone

These are the rules worth knowing, because they are where converters usually destroy data:

a leading zero keeps the value a string — 01 stays "01";
hexadecimal and exponent notation stay strings: 0x10 and 1e5 are not numbers here;
an explicit plus sign keeps it a string, +7 stays text, while -3 becomes a number;
true and false become booleans, case-sensitively — TRUE stays a string;
an empty field becomes an empty string, never null;
the text null stays the string "null", because CSV has no way to express absence.

One more, easy to miss: the space around a delimiter is part of the field. In 1, 2 the second value is " 2" — a string, with its space, not the number 2.

When a row does not match its header

It is an error, and deliberately so. Both Too many fields and Too few fields report the expected and parsed counts, which is enough to locate the line. Silently padding or truncating would shift every column after the mistake and give you a file that looks fine.

Truly blank lines are skipped. A row whose fields are all empty is kept — it is a real row.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why did my postcode 01234 stay a string?: Because a leading zero is meaningful. Converting it to a number would silently give 1234, so any value starting with a zero is kept as text — postcodes, product codes and phone numbers survive intact.
Why is my row count an error instead of a warning?: Because a row that does not match its header is ambiguous: the tool cannot know whether a field was dropped or an extra delimiter slipped in. The message tells you how many fields were expected and how many were parsed, so you can find the line.
How do I keep everything as text?: Turn off **Detect types** above the editor. Every value then comes out quoted, which is what you want when the JSON is going straight into a system that does its own parsing.