Free · Fast · Privacy-first

JSON to CSV Preserving Types

CSV is fundamentally a string format.

Native JSON tool

JSON to CSV

Runs in your browser
CSV output
Run the tool to see a task-specific result.

Numbers stay numeric

🔒

Booleans as bare true/false

Nulls as empty cells

Configurable type formatting

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

Add this JSON to CSV to your website

Drop the JSON to CSV 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/json-to-csv?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON to CSV by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

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

How types travel from JSON through CSV

JSON has six value types: string, number, boolean, null, object, and array. CSV has one: string. Bridging the gap means representing each JSON type as a string that a downstream tool can parse back into the right type on import. Numbers travel by writing them unquoted: 42, not "42". Spreadsheet and data tools coerce unquoted numeric strings to numbers automatically. Booleans travel by writing the literal tokens true and false. Most tools recognise these on import, though Excel reads them as text by default unless the column is explicitly typed. Nulls travel as empty cells, which is the convention every spreadsheet and SQL bulk-import tool recognises.

Strings travel quoted when necessary per RFC 4180. A string value that happens to look like a number, such as a ZIP code with leading zeros, needs special handling because most tools coerce it to a number on import and strip the leading zeros. FixTools offers a column-level option to wrap such strings in =" syntax, which signals text to Excel and prevents coercion. This is the difference between 00501 staying as 00501 in the CSV and becoming 501 after Excel opens the file.

Numbers with very high precision are another edge case. JSON numbers are conventionally double-precision floats per the spec, with about 15 significant digits of safe precision. Values beyond that can lose precision during parse. If your data has integers larger than 2^53 (such as Twitter snowflake IDs or some Mongo numberLong values), keep them as strings in the source JSON to preserve precision through the conversion.

Dates are not a JSON type but appear as ISO 8601 strings by convention. They travel through CSV cleanly because the string representation is preserved exactly. Excel auto-parses ISO 8601 dates as date values on import for most regional locales. For dates in non-standard formats, the downstream tool may parse them as text rather than dates, in which case you can format them as proper dates in the spreadsheet after import.

How to use this tool

💡

Preserve numeric, boolean, and null types when converting JSON to CSV so downstream tools recover them as native types.

How It Works

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

  1. 1

    Paste JSON

    Paste the JSON or upload the file. The parser detects the value types per column based on the records present.

  2. 2

    Choose null handling

    Pick how to represent nulls: empty cells (default, recommended for most tools), the literal string null, or a custom placeholder.

  3. 3

    Choose boolean handling

    Pick whether to write booleans as bare true and false, as 1 and 0, or as Yes and No. Default is true/false.

  4. 4

    Preserve string-numbers if needed

    For string values that look like numbers but should not be coerced (ZIP codes, account numbers, SKUs), enable the text-coercion option for those columns to wrap them in =" syntax.

  5. 5

    Download

    Download and open in your spreadsheet. Numbers, booleans, and dates load as their native types. String columns flagged as text preserve leading zeros and other identifier formatting.

Real-world examples

Common situations where this approach makes a real difference:

ZIP code preservation

An analyst converts a JSON address list where ZIP codes start with 0. Without text marking, Excel strips the leading zeros. With text marking enabled on the ZIP column, 00501 stays as 00501.

Snowflake ID precision

A developer converts Twitter API data containing snowflake IDs larger than 2^53. Keeping the IDs as strings in the source JSON and marking the column as text in the converter preserves full precision through the CSV.

Boolean for survey responses

A researcher converts survey response JSON with boolean answers. The converter writes Yes and No instead of true and false, which is more readable for the analyst who opens the CSV in Sheets.

Null as empty for SQL import

A data engineer prepares a CSV for COPY into PostgreSQL. Empty cells become NULL automatically in COPY. The converter's default empty-cell null handling matches PostgreSQL's expectation without per-column configuration.

Pro tips

Get better results with these expert suggestions:

1

Test type inference on first open

After downloading, open the CSV and click into a few numeric cells to confirm they read as numbers (right-aligned in Excel by default) and a few boolean cells to confirm the format. Spotting a coercion issue early saves redoing the analysis.

2

Use ISO 8601 for dates

If your source JSON has dates, ensure they are ISO 8601 strings before conversion. ISO 8601 is unambiguous and parses correctly in every modern tool. Other formats like "1/2/2024" are ambiguous (January 2 in US, February 1 in Europe) and produce inconsistent results across recipients.

3

Quote large integers as strings

For integers beyond 2^53, keep them as strings in the source JSON to preserve precision. The CSV then carries them as text, and your downstream tool treats them as identifiers rather than numbers.

4

Document null convention with recipient

If the CSV goes to a recipient with a strong null convention (database load script expecting empty cells, analyst expecting the literal "null"), confirm before sending. A one-line note saves a confused round-trip.

FAQ

Frequently asked questions

Yes. Numbers are written unquoted, and most downstream tools coerce unquoted numeric strings back to numbers on import. The CSV file itself stores them as text per the format specification, but the import-side coercion is reliable.
Booleans default to the literal tokens true and false. Alternative formats include 1 and 0 or Yes and No, selectable in the options panel. Most spreadsheet tools display true and false correctly but read them as text rather than as native boolean type.
Nulls default to empty cells, which is the convention every spreadsheet and SQL bulk-import tool recognises. Alternative formats include the literal string null, NULL, or a custom placeholder.
Excel coerces text that looks numeric into numbers and strips leading zeros. To preserve them, mark the ZIP column as text in the converter's column settings, which wraps each value in =" syntax that signals text to Excel.
JavaScript numbers lose precision above 2^53. If your data has larger integers (such as Twitter IDs), keep them as strings in the source JSON. The CSV will carry them as text, and your downstream tool will treat them as identifiers without precision loss.
Dates are written as the string they appear in the source JSON. ISO 8601 dates parse correctly in every modern tool. Non-ISO formats may read as text in the spreadsheet and need a separate date-parsing step.
No, the converter preserves numeric values exactly. If you want rounded values in the CSV, round in the source JSON or apply a rounding formula in the spreadsheet after import.

Related guides

More use-case guides for the same tool:

Ready to get started?

Open JSON to CSV to review its free limits and processing method.

Open JSON to CSV →

Free tier · No account needed · Transparent limits

Source-backed reference

JSON standards quick reference

Concise, standards-backed facts for developers working with JSON debugging and validation. Each rule links to a primary specification so it can be independently verified before you rely on it in code, documentation, or an incident report.

JSON standard
RFC 8259 defines JSON as a text format for serializing structured data. JSON values may be objects, arrays, strings, numbers, true, false, or null.
Verify in RFC 8259
Strings and object keys
JSON strings and object member names use double quotation marks. Single-quoted strings are not valid JSON syntax.
Verify in RFC 8259 §7
Trailing commas
The JSON grammar does not allow a comma after the final member of an object or the final element of an array.
Verify in RFC 8259 §4–5
Interoperability
ECMA-404 describes the JSON syntax independently of any programming language, which is why standard parsers can exchange the same JSON text across runtimes.
Verify in ECMA-404

Common invalid → valid JSON examples

Trailing comma

{"a":1,}{"a":1}

Single-quoted key

{'a':1}{"a":1}

Unsupported literal

{"score":NaN}{"score":null}

Built for verification, not just extraction

Direct answers are paired with primary sources and concrete examples. That makes this page useful to developers and also gives search and answer systems a clear, verifiable statement to reference instead of an unsupported summary.