Why This CSV to JSON Converter Never Guesses a Number Type

CSV to JSON keeps every converted value as a JSON string, even when it's a string of digits that looks exactly like a number. That's a deliberate choice worth explaining, since some other converters do the opposite by default.

What "guessing" actually means

A type-guessing converter looks at a cell's content and decides, on its own, what JSON type it should become - a cell that's all digits becomes a JSON number, "true"/"false" becomes a JSON boolean, everything else stays a string. It's presented as a convenience: your JSON comes out with real numbers instead of number-shaped strings, which is genuinely useful for some spreadsheets.

Why that convenience is a trap for a real subset of data

The problem is that CSV itself carries no type information at all - every single cell in a CSV file is text, full stop. A converter's "number" guess is really a guess about intent, and it gets it wrong for anything where a leading zero, a fixed format, or a non-numeric-but-digit-only meaning matters: ZIP codes, phone numbers, product/SKU codes, account numbers, ID numbers. A ZIP code "02139" silently becomes the number 2139, and once it's a number, the leading zero is gone for good - there's no way to tell from the number 2139 alone that it should have five digits.

Why this tool draws the line at "never guess"

Rather than trying to guess well - which usually means a pile of special cases for "looks like a ZIP" or "looks like a phone number," and inevitably still gets some of them wrong - this tool draws a simpler, more reliable line: nothing is ever guessed. What you see in the CSV cell is exactly what lands in the JSON string value, whether that's "42", "true", or "02139". You get back exactly what you put in, which is the one guarantee a converter can actually keep.

If you do want real numbers in your JSON

For data where the cells genuinely are meant to be numeric - a price column, a quantity column, something you're about to run math on - converting the string values to numbers afterward, in whatever script or tool consumes the JSON, is a one-line, deliberate step you control. That's a meaningfully different thing from a converter doing it silently and universally before you ever see the result, because you get to decide it column by column, only where it's actually correct.

Where this fits into the bigger picture

This same "don't guess, stay honest" reasoning is the whole design of the parser underneath this tool - quoted fields, embedded commas, and ragged rows are all handled by understanding CSV's real rules rather than approximating them. See the background piece for the other traps a naive converter walks into, or the how-to guide for the actual steps. Or convert a file now.