Last week a JSON-to-Excel tool quietly changed my data and I almost shipped it to a client.

I pasted an API response into the top "JSON to Excel" tool on Google, downloaded the file, and opened it - an order ID ending in ...3456 now ended in ...3400.

No error. No warning. The spreadsheet looked perfect. The data was just wrong.

That's the worst kind of bug - the silent one. You trust it, you ship it, and you find out weeks later when the numbers don't reconcile.

Then I found out why. It's not really the tool's fault. It's JavaScript.

The 10-second demo that should scare you

Open your console:

JSON.parse('{"id": 1099511627776123456}').id
// → 1099511627776123400   ❌ last digits gone

JSON.parse('{"id": 9007199254740993}').id
// → 9007199254740992      ❌ off by one

JS numbers are IEEE-754 doubles. The largest integer they hold exactly is Number.MAX_SAFE_INTEGER = 9007199254740991 (2⁵³−1). Anything bigger - 64-bit DB IDs, Discord/Twitter snowflakes, GST invoice numbers - gets rounded by JSON.parse before your converter even runs.

The kicker: even if a tool parses it right, Excel also stores numbers as float64 so it has to write the value as a text cell or the rounding comes right back. Most tools don't.

Three more traps

Leading zeros → Number("007890") is 7890. Account numbers and PINs die instantly.

Formula injection → a cell value of =1+1 (or =HYPERLINK(...)) can execute when Excel opens the file. If that JSON came from user input, it's a security hole. Safe tools write it as text.

Dates → some tools silently timezone-shift 2026-03-31 into a different value. You won't catch it unless you look hard.

The 30-second test (save this)

Paste this into any converter, open the result, check three things:

[
  { "id": 1099511627776123456 },
  { "acct": "007890" },
  { "price": 99.5 }
]

1. Did the ID keep all 19 digits?
2. Did 007890 keep its leading zero?
3. Is 99.5 still a number you can SUM (not text)?

Fail any one, and you've been shipping subtly wrong spreadsheets.

Doing it right

A correct converter threads a needle: preserve unsafe values (big IDs, leading zeros) as text, but keep clean numbers numeric so you can still do math - guard formula cells, leave dates alone unless asked.

I got tired of tools that didn't, so I built one that does - client-side, so your JSON never leaves the browser (it's data; it shouldn't): jsontoexcel.in. Free, no signup, passes the test above, handles nested JSON, and even parses Indian GST returns (GSTR-2A/2B/1) that most tools choke on. It is not limited to single input format only. It handles 15-20 input formats similar to JSON/NDJSON.

In a nested-data section: "…here's how it flattens nested JSON into columns.

In a logs/data section: "…for log files, see converting NDJSON to Excel

it even handles GST returns like GSTR-2B

But seriously - whatever tool you use, run the test first. 30 seconds now beats a corrupted report later.

What's the worst silent data corruption that's bitten you? Drop it below 👇 - I'm collecting edge cases.