It seems like there is no maximum limit to a BigInt as per spec, which makes sense considering BigInts are supposed to be arbitrary-precision integers, whose "digits of precision are limited only by the available memory of the host system".

As for v8 specifically, according to this article on the v8 blog, the precision of BigInts are "arbitrary up to an implementation-defined limit". Unfortunately, I couldn't find any further information on how the limit is determined. Maybe someone else would be able to shed light on this based on these v8 BigInt implementation notes?

That said, based on the aforementioned articles, there doesn't seem to be a specific maximum value/size for a BigInt. Rather, it is likely determined based on the available memory on the system in some way.

Note: below measurements were taken in V8 (Chromium), should extend to other engines to confirm and post links to benchmarks.

Note 2: all these functions assume the argument is nonnegative, and may crash / loop / return invalid results otherwise.

simple version

return x.toString(2).length

as pointed out in the comments, even if it feels hacky to use toString(), it's unlikely there's an asymptotically faster way (because formatting a base 2 string is efficient and happens natively). it's O(n) with the number of bits of the bigint. other than that it's short and readable, so it's ideal for most uses.

better version

const i = (x.toString(16).length - 1) * 4
return i + 32 - Math.clz32(Number(x >> BigInt(i)))

this still uses the toString() approach, but it uses base 16 instead of base 2, meaning the temporary string that is produced is 4x shorter. formatting base 16 is also efficient, no real base change required, so still O(n).

the gains of using this are marginal for small bigints (+10% for 32 bits) but for big ones (such as messages or cryptography coefficients, meaning 512 / 1024 / 2048 / 4096) it's 2.5 to 4 times faster and puts less pressure on the GC as it only allocates a 2x long string. it's ideal for hot code and non-small integers.

"you may be overthinking this" version

there's fortunately a more performant way that does not involve toString() and instead relies on pre-allocated integers of different sizes that are successively compared to the target to get an upper bound for its size, in ceil(log2(n)) steps.

once the upper bound is established, the exact size is determined by bisection:

// find upper bound
let k = 0
while (true) {
    if (testersN === k) {
        testersCoeff.push(32 << testersN)
        testersBigCoeff.push(BigInt(testersCoeff[testersN]))
        testers.push(1n << testersBigCoeff[testersN])
        testersN++
    }
    if (x < testers[k]) break
    k++
}

if (!k)
    return 32 - Math.clz32(Number(x))

// determine length by bisection
k--
let i = testersCoeff[k]
let a = x >> testersBigCoeff[k]
while (k--) {
    let b = a >> testersBigCoeff[k]
    if (b)
        (i += testersCoeff[k], a = b)
}

return i + 32 - Math.clz32(Number(a))

this code uses the following global variables to store cached state:

const testersCoeff = []
const testersBigCoeff = []
const testers = []
let testersN = 0

in my tests, compared with the previous version, this is 2x faster for 512 bits, 7x faster for 4096 bits. it allocates at most 1x the size of the target integer, albeit in multiple integers.

ideal version

with proper native support, this would essentially be a O(1) operation (since the engine needs to know the length of the buffer used to store the bigint).

as for now, the best thing we can hope for is O(n) since there's no way to probe for the size of a bigint (i.e. ask if size is smaller or larger than a certain n) that does not involve an allocation proportional to n in the worst case.

Doesn't BigInt have the same upper bound?

No, BigInts have no specified limit. That said, realistically, there will always be implementation-defined limits (just like for Strings, Arrays, etc.). Currently, Chrome allows a billion bits, and Firefox allows a million bits. The expectation is that most realistically-occurring BigInts won't run into this limit.

Does BigInt represent number in 64-bit format IEEE-754?

No, IEEE-754 is a floating-point format, so it's not useful for BigInts, which have integer values. Besides, they have "unlimited" precision.

can the BigInt value take up more space than 64 bits?

Yes, BigInts can consume a lot more than 64 bits. For example, a BigInt with a thousand bits (such as 2n ** 999n) will need (about) a thousand bits of memory (likely rounded up to the next multiple of 4 or 8 bytes, plus a small object header, specifics depend on the engine).

Javascript represents all numbers as 64-bit double precision IEEE 754 floating point numbers (see the ECMAscript spec, section 8.5.) All positive integers up to 2^53 can be encoded precisely. Larger integers get their least significant bits clipped. This leaves the question of how can you even represent a 64-bit integer in Javascript -- the native number data type clearly can't precisely represent a 64-bit int.

The following illustrates this. Although javascript appears to be able to parse hexadecimal numbers representing 64-bit numbers, the underlying numeric representation does not hold 64 bits. Try the following in your browser:

<html>
  <head>
    <script language="javascript">
      function showPrecisionLimits() {
        document.getElementById("r50").innerHTML = 0x0004000000000001 - 0x0004000000000000;
        document.getElementById("r51").innerHTML = 0x0008000000000001 - 0x0008000000000000;
        document.getElementById("r52").innerHTML = 0x0010000000000001 - 0x0010000000000000;
        document.getElementById("r53").innerHTML = 0x0020000000000001 - 0x0020000000000000;
        document.getElementById("r54").innerHTML = 0x0040000000000001 - 0x0040000000000000;
      }
    </script>
  </head>
  <body onload="showPrecisionLimits()">
    <p>(2^50+1) - (2^50) = <span id="r50"></span></p>
    <p>(2^51+1) - (2^51) = <span id="r51"></span></p>
    <p>(2^52+1) - (2^52) = <span id="r52"></span></p>
    <p>(2^53+1) - (2^53) = <span id="r53"></span></p>
    <p>(2^54+1) - (2^54) = <span id="r54"></span></p>
  </body>
</html>

In Firefox, Chrome and IE I'm getting the following. If numbers were stored in their full 64-bit glory, the result should have been 1 for all the substractions. Instead, you can see how the difference between 2^53+1 and 2^53 is lost.

(2^50+1) - (2^50) = 1
(2^51+1) - (2^51) = 1
(2^52+1) - (2^52) = 1
(2^53+1) - (2^53) = 0
(2^54+1) - (2^54) = 0

So what can you do?

If you choose to represent a 64-bit integer as two 32-bit numbers, then applying a bitwise AND is as simple as applying 2 bitwise AND's, to the low and high 32-bit 'words'.

For example:

var a = [ 0x0000ffff, 0xffff0000 ];
var b = [ 0x00ffff00, 0x00ffff00 ];
var c = [ a[0] & b[0], a[1] & b[1] ];

document.body.innerHTML = c[0].toString(16) + ":" + c[1].toString(16);

gets you:

ff00:ff0000

MDN doc

BigInt is a built-in object that provides a way to represent whole numbers larger than 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant. BigInt can be used for arbitrarily large integers.

Difference:

• BigInt cannot be used with methods in the built-in Math object and cannot be mixed with instances of Number in operations
• Because coercing between Number and BigInt can lead to loss of precision, it is recommended to only use BigInt when values greater than 2^53 are reasonably expected and not to coerce between the two types.