How to handle 64-bit IDs in JSON with JavaScript BigInt

Step 01: Check whether your IDs are unsafe

Number.MAX_SAFE_INTEGER                        // 9007199254740991
Number.isSafeInteger(JSON.parse('175928847299117063'))  // false

Rule of thumb: any integer with 17 or more digits is unsafe; 16-digit ones are unsafe above 9,007,199,254,740,991. Paste a real response into the checker above to see exactly which fields break.

Step 02: Fix it at the source: send IDs as strings

If you own the API, this is the fix that works for every client, in every language, forever. Discord's API documents that it returns every Snowflake as a string for this reason, and X's API pairs id with an id_str field (X docs).

json.dumps({"id": str(row.id)})          # {"id": "175928847299117063"}

// Go: the ,string option writes and reads the int64 as a JSON string
type User struct {
    ID int64 `json:"id,string"`
}

-- Postgres: cast in the query that builds the JSON
SELECT json_build_object('id', id::text) FROM users;

Keep the column a 64-bit integer in the database; only the JSON gets the string. The Go encoding/json docs describe the string option.

Step 03: If you cannot change the server, parse with a reviver

Since the "JSON.parse source text access" proposal reached Stage 4 at TC39 (champions Richard Gibson and Mathias Bynens), revivers get a third argument, ctx, whose source is the original text of each primitive. That text still has every digit:

const data = JSON.parse(body, (key, value, ctx) =>
  key === 'id' ? BigInt(ctx.source) : value);
data.id   // 175928847299117063n

Only convert the fields you know are IDs. Converting every number to BigInt breaks arithmetic with normal numbers (1n + 1 throws a TypeError).

Step 04: On older runtimes, use a library

ctx.source is missing in Node.js 20 and earlier and in browsers from before 2025; there the third argument is undefined. Two maintained parsers read big integers without going through a float:

// npm i json-bigint
const JSONbig = require('json-bigint')({ useNativeBigInt: true });
JSONbig.parse('{"id":175928847299117063,"n":5}');
// { id: 175928847299117063n, n: 5 }   small numbers stay numbers

json-bigint (by Andrey Sidorov) had 37.2 million npm downloads in the week of October 16 to 22, 2026; lossless-json (by Jos de Jong) had 1.2 million and wraps numbers in a LosslessNumber class instead.

Step 05: Send BigInts back without a TypeError

JSON.stringify({ id: 1n }) throws TypeError: Do not know how to serialize a BigInt. Pass a replacer:

// As a string (what most APIs want):
JSON.stringify(data, (k, v) => typeof v === 'bigint' ? v.toString() : v);
// {"id":"175928847299117063"}

// As a bare JSON number, exact (Node.js 22+, Baseline 2025 browsers):
JSON.stringify(data, (k, v) => typeof v === 'bigint' ? JSON.rawJSON(v.toString()) : v);
// {"id":175928847299117063}

Step 06: Test the round trip

const raw = '{"id":175928847299117063}';
const out = JSON.stringify(parse(raw), replacer);
assert.equal(out, '{"id":"175928847299117063"}'); // or the raw form

Use an ID above 2^53 in the fixture. Tests with small IDs like 42 pass even when the bug is there, which is how this ships to production.