What is BigInt in JavaScript?

BigInt is a JavaScript primitive type (introduced in ES2020) that represents integers of arbitrary size. Unlike the Number type — which is a 64-bit IEEE 754 float and safely represents integers only up to 2⁵³−1 — BigInt has no upper bound.

How is BigInt used in practice?

Ethereum token amounts are stored in wei, where 1 ETH = 10¹⁸ wei. That 19-digit number exceeds the safe integer range of Number, so Ethereum libraries like ethers.js use BigInt (or its predecessors BN.js/JSBI) for all on-chain arithmetic.

What is the difference between BigInt and Number in JavaScript?

Number uses floating-point and loses precision above 2⁵³−1 (9,007,199,254,740,991). BigInt uses arbitrary-precision integer arithmetic and never loses precision, but cannot represent fractions. You cannot mix the two in arithmetic without explicit conversion.

Are there performance trade-offs with BigInt?

Yes — BigInt operations are significantly slower than Number operations because they cannot use CPU floating-point hardware. For amounts that fit within Number's safe integer range, using Number is faster; BigInt is only necessary when values exceed 2⁵³−1.

Glossary

BigInt

JavaScript's arbitrary-precision integer type

By Buğra SözeriPublished May 14, 2026Updated May 31, 2026

BigInt is a JavaScript primitive type added in ES2020 for arbitrary-precision integer arithmetic. Unlike the regular Number type — which uses IEEE 754 double precision and loses accuracy past about 2⁵³ — BigInt can represent integers of any size.

Literal syntax: append n to a number, or call BigInt(x). Operators like +, -, *, / work, but you can’t mix BigInt with Number — 1n + 1 throws. Division truncates toward zero (integer division).

Where BigInt matters: Ethereum Wei amounts (up to 10¹⁸ per ETH), cryptographic operations (RSA keys, ECC), large database IDs (Snowflake, ULID), counters at scale, financial systems that store cents as integers.

Our Wei / Gwei / ETH converter uses BigInt throughout so 18-digit Wei amounts round-trip without loss. See our crypto methodology for the implementation details.

Where Number silently breaks before BigInt: the boundary is Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9,007,199,254,740,991. Above this, consecutive integers are no longer all representable — 9007199254740992 and 9007199254740993 round to the same double. JSON parsers that do not opt into BigInt support quietly mangle large IDs returned from APIs (Twitter snowflake IDs, Stripe object IDs in 64-bit accounts, Ethereum amounts). The corruption is silent: no exception, no warning, just a different number. JSON.parse can be configured with a reviver function that detects integer strings and converts them to BigInt explicitly.

BigInt and serialisation: JSON.stringify(1n) throws a TypeError by default — JSON has no BigInt type. The pragmatic workaround is to serialise BigInts as decimal strings and parse them back on the consuming side, which is what every blockchain RPC API does (Ethereum returns hex strings, Solana returns decimal strings). Avoid the temptation to .toString() on the way out and Number() on the way in — that completes a round trip through the lossy type and defeats the point. Related: IEEE 754 (why 0.1 + 0.2 !== 0.3 in the same language), Wei, Gwei. Reference: TC39 BigInt proposal.

Worked example: ETH balance arithmetic

Consider an account holding 1.234567890123456789 ETH, stored on-chain as 1234567890123456789 Wei. As a JavaScript Number this becomes 1234567890123456800 — the last two digits are gone. The error (about 11 wei) is tiny in fiat terms, but if you sum many such balances during accounting reconciliation, the rounding bias compounds and the off-chain ledger diverges from the on-chain truth. With BigInt: const bal = 1234567890123456789n; const fee = 21000n * 30n * 10n**9n; const net = bal - fee; — exact to the wei, no loss. The 10n**9n term is a billion, the gwei-to-wei multiplier.

Performance and gotchas

BigInt operations are slower than Number — typically 10-100× depending on operand size — because they touch arbitrary-precision arithmetic in V8 rather than a single CPU instruction. For hot loops over millions of values that fit safely in a double, stick with Number. Other pitfalls: Math.max, Math.abs, Math.floor reject BigInt; JSON.stringify throws; typeof 1n === "bigint", not "number"; mixing types with < and === follows surprising coercion rules (1n == 1 is true, 1n === 1 is false). MDN’s BigInt reference enumerates the coercion table; treat it as a checklist when introducing BigInt into a previously Number-only codebase.

Frequently asked questions

What is BigInt in JavaScript?: BigInt is a JavaScript primitive type (introduced in ES2020) that represents integers of arbitrary size. Unlike the Number type — which is a 64-bit IEEE 754 float and safely represents integers only up to 2⁵³−1 — BigInt has no upper bound.
How is BigInt used in practice?: Ethereum token amounts are stored in wei, where 1 ETH = 10¹⁸ wei. That 19-digit number exceeds the safe integer range of Number, so Ethereum libraries like ethers.js use BigInt (or its predecessors BN.js/JSBI) for all on-chain arithmetic.
What is the difference between BigInt and Number in JavaScript?: Number uses floating-point and loses precision above 2⁵³−1 (9,007,199,254,740,991). BigInt uses arbitrary-precision integer arithmetic and never loses precision, but cannot represent fractions. You cannot mix the two in arithmetic without explicit conversion.
Are there performance trade-offs with BigInt?: Yes — BigInt operations are significantly slower than Number operations because they cannot use CPU floating-point hardware. For amounts that fit within Number's safe integer range, using Number is faster; BigInt is only necessary when values exceed 2⁵³−1.

Published May 14, 2026 · Last reviewed May 31, 2026