Free · Fast · Privacy-first

CSV to JSON with Types

CSV stores everything as text.

Native JSON tool

CSV to JSON

Runs in your browser

CSV input

JSON output

Run the tool to see a task-specific result.

⚡

Smart type inference

🔒

Per-column promotion

✨

Safe string fallback

⚡

Browser-only processing

Cost: Free tier
Sign-up: Not required
Processing: Tool-specific
Privacy: Clearly disclosed

IframeResponsiveAttribution included

Add this CSV to JSON to your website

Drop the CSV to JSON into a blog post, product docs, intranet, or school portal with one iframe. Processing, privacy, and usage limits are the same as on the full tool page.

One copy-ready line of HTML
Responsive — adapts to any container width
No API credentials are placed in the snippet

Embed code

<iframe
  src="https://www.fixtools.io/json/csv-to-json?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="CSV to JSON by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/csv-to-json?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="CSV to JSON by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

How conservative type inference avoids surprises

The naive approach to typing is to look at each cell individually: if it parses as a number, emit a number; otherwise emit a string. This produces JSON where the same column has numbers in some rows and strings in others, which breaks consumers that assume a column has a single type. FixTools takes the column-wide approach instead. It inspects every non-empty cell in a column, and only promotes the entire column to a more specific type when every cell parses cleanly as that type. A single non-numeric cell in an otherwise numeric column keeps the entire column as strings, which is the safe default because mixed-type fields are harder to consume than uniformly typed strings.

The type hierarchy works as follows. Boolean is checked first: a column where every non-empty cell is exactly true or false (case-insensitive) becomes boolean. Otherwise, integer is checked: a column where every non-empty cell parses as a signed integer becomes integer JSON. Otherwise, decimal is checked: a column where every non-empty cell parses under the JSON number grammar including decimals and scientific notation becomes JSON number. Otherwise the column stays as strings. Empty cells in any non-string column become null because there is no zero-value representation in JSON that means missing for numbers or booleans.

Special tokens like Yes, No, T, F, 1, and 0 are not auto-promoted to boolean by default because the same tokens can mean different things in different domains. A column labelled active with values yes and no is probably boolean intent, but a column labelled rating with values 1 through 5 is integer intent that happens to have rows of 1 and 0 elsewhere. The conservative default treats Yes and No as strings unless you explicitly enable a Boolean Tokens option that lists which tokens to accept. This avoids accidental type promotions that silently change the meaning of your data.

Currency, percentages, and units are not auto-stripped. A cell containing 100.00 USD stays a string because it cannot parse as a number under JSON syntax. If you want a numeric column, strip the units in the spreadsheet before exporting. This rule sounds restrictive but it avoids ambiguous decisions like whether to drop the units symbol or convert it into a separate field. Keeping the converter focused on structural parsing rather than data cleaning makes the pipeline easier to reason about: cleaning is the spreadsheet job and conversion is the structural job.

MDN: JSON.parse RFC 8259: JSON spec

How to use this tool

💡

Type inference is on by default. Columns become numbers, booleans, or null automatically when every cell fits, otherwise stay as strings.

How It Works

Step-by-step guide to csv to json with types:

1
Clean your CSV first
Before conversion, strip units, currency symbols, and stray characters from cells that should be numeric. A column with values 100, 200, 300 USD will stay as strings because of USD, but the same column with 100, 200, 300 will become numbers. Five minutes of spreadsheet cleanup pays off in proper JSON typing.
2
Paste or upload
Open the converter and load your cleaned CSV. The tool detects headers and prepares to type-infer each column independently.
3
Click Convert
Press Convert. The tool runs type inference per column then emits JSON with the correct primitive types per value. Inspect the preview to confirm numeric columns appear without quotes.
4
Spot-check edge cases
Find any cells that are blank, contain non-standard characters, or look unusual, and verify the JSON treats them as expected. Empty cells in numeric columns should be null. Empty cells in string columns should be empty string unless Keep Nulls is enabled.
5
Download the typed JSON
Copy or download the output. Downstream code can use the values directly without parseInt, parseFloat, or string-to-boolean conversion calls.

Real-world examples

Common situations where this approach makes a real difference:

Financial data feeding a chart library

A frontend developer imports a price history CSV and feeds it into a chart library that expects numeric x and y values. With type inference the JSON arrives ready to use; without it, every value would need parseFloat before chart rendering and a stray non-numeric cell would crash the chart.

Configuration with boolean toggles

A platform team maintains feature flag definitions as a CSV with active TRUE/FALSE columns. Type-inferred conversion produces JSON with real booleans the runtime branches on directly, avoiding the bug where if (config.active) evaluates "false" as truthy.

Sensor data ingestion

An IoT engineer converts a CSV of sensor readings where some readings are missing. Type inference promotes the value column to number and missing cells become null. The downstream analytics pipeline knows the difference between a real zero reading and a missing reading.

Survey results to analysis tool

A researcher exports survey responses with Likert-scale numeric answers and demographic strings. Type inference numerifies the Likert columns and stringifies the demographic columns automatically, producing a JSON shape the analysis notebook ingests directly.

Pro tips

Get better results with these expert suggestions:

Disable inference for known-string columns

For columns like postcode or phone number that look numeric but should stay as strings to preserve leading zeros or formatting, disable inference for those columns or add a non-numeric character somewhere in the column header to signal intent. Loss of leading zeros is a classic CSV-to-numeric pitfall.

Use null for missing values consistently

Enable Keep Nulls if your downstream consumer differentiates between empty string and null. JavaScript treats both as falsy in boolean contexts but they differ in JSON.stringify roundtrips and in SQL NULL semantics. Pick the representation that matches your target schema.

Audit one row of each column type before shipping

Open the JSON output and inspect one example of each column in the first row. Confirm that the values you see have the types you expected. This sanity check takes thirty seconds and catches inference mismatches before they reach production.

Re-run after data updates

When the source CSV is updated, re-run conversion rather than hand-editing the JSON. If new rows introduce non-numeric values in a previously numeric column, the converter will demote that column to strings automatically, surfacing the schema change instead of hiding it under stale typing.

FAQ

Frequently asked questions

The tool inspects every non-empty cell in a column. If all cells are true or false (case-insensitive), the column becomes boolean. If all cells parse as integers, it becomes integer. If all parse as JSON numbers including decimals, it becomes number. Otherwise it stays as string. This column-wide rule avoids mixed types within one field.

The whole column falls back to strings. This is conservative but safe: consumers can rely on uniform types per column. To fix, identify the offending cell in your CSV (often a stray comma, currency symbol, or N/A token), clean it, and re-convert.

Only if the column stays as strings. A column where every cell parses as a number will become numeric and leading zeros are lost because JSON numbers do not represent them. For postcodes, phone numbers, and ID strings that need leading zeros, ensure at least one non-numeric character keeps the column as strings, or disable inference for that column.

By default, yes. The tool treats only true and false case-insensitively as boolean. You can enable Yes/No, 1/0, or T/F as boolean tokens through a setting, but the defaults are conservative because those tokens have ambiguous meaning in many domains.

They stay as strings. JSON has no native date type, and inferring an ISO format requires choosing a parsing locale. The conservative behaviour is to leave them as strings exactly as they appear in the CSV. Downstream consumers can parse them with a date library if needed.

When enabled, every empty CSV cell becomes JSON null regardless of column type. When disabled, empty cells become null only in numeric or boolean columns, and become empty string in string columns. Pick the behaviour that matches your target schema.

Yes. JSON numbers accept scientific notation like 1.23e10. Cells with this notation in a numeric column will be emitted as JSON numbers using the same notation. Be aware that very large or very small numbers may lose precision when round-tripped through JavaScript Number, which is double-precision floating point.

Yes. Disable type inference entirely. Every cell is then emitted as a JSON string with no coercion. This is occasionally useful when you want to preserve exact text representation, but most downstream consumers benefit from typed output so the inference default is usually what you want.

null is a distinct JSON value meaning explicitly no value. Empty string is a string with zero characters. Consumers that check x === null behave differently than those that check x === "". SQL NULL maps to JSON null, not empty string. Pick the representation that matches your target schema and stick to it.