JavaScript has one number type: a 64-bit IEEE-754 double. That gives exact integers only up to 2^53 − 1, and it cannot represent most decimals exactly, which is why 0.1 + 0.2 !== 0.3. BigInt adds arbitrary-precision integers but does not mix with Number.
Before you start
You should be comfortable with numbers and equality in JavaScript. This article explains the representation limits and the BigInt rules; it does not cover a specific decimal library.
Step-by-step walkthrough
Step 1: Respect the safe integer range
Number.isSafeInteger returns true only for integers between -(2^53 - 1) and 2^53 - 1. Beyond that, two distinct integers can map to the same double, so IDs from a distributed generator can silently collide. Compare Number.MAX_SAFE_INTEGER before trusting an integer.
Step 2: Treat money as scaled integers
Because 0.1 has no exact binary representation, summing prices accumulates error. Store amounts in the smallest unit (cents) as integers and format at the edge, or use a decimal library when rounding rules are business-critical.
Step 3: Use BigInt for exact large integers
BigInt represents integers of any size exactly. You cannot mix it with Number in arithmetic (1n + 1 throws a TypeError), it cannot be used with Math methods, and it has no fractional part. Parse with BigInt(value) or the 10n literal and serialize carefully, since JSON.stringify throws on BigInt.
Worked scenario
Run this with Node.js to see the representation limits directly.
console.log(0.1 + 0.2); // 0.30000000000000004
console.log(Number.isSafeInteger(2 ** 53)); // false
console.log(9007199254740993n); // 9007199254740993n (exact)
try { console.log(1n + 1); } catch (error) { console.log(error.constructor.name); } // TypeErrorWalk through the example
The first line shows decimal drift: the sum is not exactly 0.3. 2 ** 53 is just outside the safe range, so isSafeInteger is false even though the number is finite. The BigInt literal prints exactly, and the mixed addition throws, which forces you to convert deliberately instead of accidentally losing precision.
Common mistake
Parsing a large ID with Number and losing low-order digits, or storing currency as floating-point dollars. A subtler mistake is comparing BigInt and Number with ===: 1n === 1 is false because the types differ, even though 1n == 1 is true.
Verify the behavior
Assert that 0.1 + 0.2 does not equal 0.3 and that rounding at the display layer fixes presentation without changing the value. Check Number.isSafeInteger around the boundary. Confirm BigInt arithmetic stays exact and that mixing types throws so you catch it early. Test JSON.stringify on a BigInt to see the failure you must handle.
Interview exercise
An order total must be summed across 10,000 line items in cents. Should you use Number or BigInt?
Answer and reasoning
Number is fine while every value and the running total stay within the safe integer range, which is true for realistic order sizes in cents. Use BigInt if totals can exceed 2^53 - 1 or if identifiers are large. In both cases, keep values as integers rather than floating-point currency, because the real risk is decimal representation error, not the integer range.
Continue learning
Review comparison rules in JavaScript equality and coercion and read the MDN BigInt reference. Try the JavaScript interview questions.