Why your JSON formatter silently changes your IDs

Shank — Sun, 11 Oct 2026 15:00:04 +0000

I needed a clean JSON tool. The ones I found came with ads all over the editor, cookie walls, "create an account to format this JSON", and no idea where my pasted data was going.

So I built my own, and along the way I learned about something worse than clutter: paste a big ID into a lot of JSON tools and it comes back different.

// What you paste
{ "order_id": 9007199254740993 }

// What a typical formatter shows you
{ "order_id": 9007199254740992 }

No warning. No error. Just a different number, off by one, that looks perfectly normal. Copy that ID into a support ticket or a database query and you're chasing an order that doesn't exist.

Why it happens

Most JSON tools on the web do roughly this:

const pretty = JSON.stringify(JSON.parse(input), null, 2);

The problem is in the middle. JSON.parse turns every number into a JavaScript Number, which is a 64-bit floating point value. Floats can only store whole numbers exactly up to:

Number.MAX_SAFE_INTEGER // 9007199254740991

Above that, there aren't enough bits, so the number gets rounded to the nearest one a float can hold:

JSON.parse('{"id": 9007199254740993}').id
// 9007199254740992

JSON.parse('12345678901234567890')
// 12345678901234567000

Then JSON.stringify writes the rounded value back out, and it looks completely normal.

Where this actually bites

It's not just a curiosity. Big integers show up all the time:

Database IDs: BIGINT primary keys and Snowflake-style IDs easily go past 2⁵³.
Social and chat platforms: Twitter/X famously had to add id_str to its API for exactly this reason, and Discord sends its IDs as strings.
Payments and tracking numbers: anything long and numeric that was never meant to be "math".

If one of those passes through a tool that parses it as a Number, you get a valid-looking ID that points to the wrong thing, or to nothing.

How to avoid it in your own code

1. Send big IDs as strings. This is the real fix. "9007199254740993" survives everything.

2. If you can't change the API, don't parse those numbers as Number. Newer JavaScript engines (recent Chrome and Node) let a reviver see the original text of each value:

const data = JSON.parse(raw, (key, value, context) =>
  key === 'order_id' ? BigInt(context.source) : value
);

data.order_id // 9007199254740993n

On older runtimes, a library like json-bigint does the same job.

3. Be careful with tools. Formatters, log viewers and "pretty print" browser extensions often parse first and print second. If an ID matters, check that the tool doesn't touch number values.

So I built a cleaner one

I wanted a JSON formatter that never touches my data, without the usual nonsense: no ads covering the editor, no "create an account to format this JSON", and nothing uploaded to a server.

I couldn't find one I liked, so I made it: CodeSwatch.

Big numbers stay exact. It uses its own parser that keeps every number as the text you wrote, so 9007199254740993 stays 9007199254740993.
Plain-English errors with the line and column, and a jump to the problem.
Repair JSON: fixes trailing commas, single quotes, comments, True/None, missing brackets and cut-off data in one click. Handy for JSON that came out of an LLM.
Folds like VS Code, with a path bar that shows where you are (root › items › [3] › id) and copies it as JSONPath.
Runs in your browser. Nothing you paste is sent anywhere, so it's fine for real API responses.

It also has a JWT decoder, a timestamp converter, Base64 and a few color tools, all in the same spirit.

It's free. I needed a clean tool, so I made it. Here you go. 🙂

If something breaks or you want a tool added, I'd love to hear it in the comments.

DEV Community: Shank

Why your JSON formatter silently changes your IDs

Why it happens

Where this actually bites

How to avoid it in your own code

So I built a cleaner one