Quando Você Pode Precisar de BigInt em JavaScript?

Mar 22, 2026 · 4 min read

Quando Você Pode Precisar de BigInt em JavaScript?

JavaScript lida com a maioria dos números muito bem — até não lidar mais. Se você já buscou um ID grande de uma API e percebeu que ele voltou ligeiramente errado, ou tentou fazer aritmética precisa com um inteiro muito grande e obteve um resultado sutilmente incorreto, você já encontrou o problema que o BigInt resolve.

Principais Conclusões

Os números JavaScript usam o formato de ponto flutuante de precisão dupla IEEE 754, que limita inteiros seguros ao intervalo −(2⁵³ − 1) a 2⁵³ − 1. Além disso, os valores perdem precisão silenciosamente.
BigInt é um tipo primitivo (introduzido no ES2020) que representa inteiros de tamanho arbitrário, mas não pode lidar com decimais.
Casos de uso do mundo real incluem o manuseio de IDs externos grandes (por exemplo, Twitter Snowflake IDs), inteiros WebAssembly de 64 bits e aritmética exata para contadores grandes ou dados de blockchain.
BigInt não pode ser misturado com Number em expressões, não funciona com a API Math e requer tratamento personalizado para serialização JSON.

O Limite que os Números JavaScript Não Podem Ultrapassar

Todos os números JavaScript usam o formato de ponto flutuante de precisão dupla IEEE 754. Isso fornece um intervalo de inteiros seguros de −(2⁵³ − 1) a 2⁵³ − 1, representado por Number.MIN_SAFE_INTEGER e Number.MAX_SAFE_INTEGER.

Além desse limite, os inteiros perdem precisão silenciosamente:

console.log(9007199254740991 + 1)  // 9007199254740992 ✅
console.log(9007199254740991 + 2)  // 9007199254740992 ❌ (errado)

// Este é o problema de precisão em ação:
9007199254740992 === 9007199254740993 // true — são iguais para o JavaScript

Nenhum erro é lançado. O valor está simplesmente errado. Esse é o problema de limite de precisão que o BigInt foi projetado para resolver.

O Que BigInt Realmente É

BigInt é um tipo primitivo integrado do JavaScript introduzido no ES2020 que pode representar inteiros de tamanho arbitrário, limitado apenas pela memória disponível. Você cria um adicionando n a um literal inteiro ou usando o construtor BigInt():

const big = 9007199254740993n                 // sintaxe literal
const alsoBig = BigInt("9007199254740993")    // construtor com string

9007199254740992n === 9007199254740993n        // false ✅ — correto

Uma restrição importante: BigInt é apenas para inteiros. Ele não pode representar decimais ou valores fracionários. 1.5n lança um SyntaxError.

Quando Usar BigInt em JavaScript

A maioria do código frontend nunca precisa de BigInt. Mas alguns cenários do mundo real genuinamente o exigem.

IDs grandes de sistemas externos. O sistema Snowflake ID do Twitter e esquemas de ID distribuídos similares produzem inteiros de 64 bits que excedem Number.MAX_SAFE_INTEGER. Quando uma API REST retorna um desses como um número JSON, o JavaScript irá corrompê-lo silenciosamente. Analisá-lo como uma string e convertê-lo para BigInt preserva o valor exatamente.

// Um ID de 64 bits recebido como string de uma API
const userId = BigInt("922337203685477580")

Inteiros de 64 bits do WebAssembly. O tipo i64 do WebAssembly mapeia diretamente para BigInt em JavaScript. Se seu módulo Wasm retorna ou aceita inteiros de 64 bits, você precisará de BigInt para lidar com eles corretamente.

Aritmética exata de inteiros onde a precisão nunca deve falhar. Certos valores de transação blockchain, contadores grandes ou aritmética de timestamp de alta precisão (por exemplo, nanossegundos desde a época) podem exceder o intervalo de inteiros seguros. BigInt mantém cada dígito exato.

Restrições Importantes a Conhecer

Antes de recorrer ao BigInt, entenda suas limitações:

Você não pode misturar BigInt e Number em aritmética. Fazer isso lança um TypeError. É necessária conversão explícita:

const big = 10n
const num = 5

big + num            // ❌ TypeError
big + BigInt(num)    // ✅ 15n
Number(big) + num    // ✅ 15 (mas perde precisão BigInt para valores grandes)

A API Math não funciona com BigInt. Math.max(), Math.sqrt() e todos os outros métodos Math lançarão erro se receberem um BigInt. Se você precisar dessas operações, precisará converter — e aceitar o compromisso de precisão.

A serialização JSON falha por padrão. JSON.stringify() lança um TypeError em valores BigInt. Você precisa de um replacer personalizado ou um método toJSON() para lidar com a serialização:

BigInt.prototype.toJSON = function () {
  return this.toString()
}

JSON.stringify({ id: 922337203685477580n }) // '{"id":"922337203685477580"}'

Observe que isso converte o valor para uma string na saída JSON, que o sistema receptor precisa lidar adequadamente. Além disso, modificar um protótipo integrado como BigInt.prototype é geralmente desencorajado em código de produção. Uma função replacer personalizada passada para JSON.stringify() é uma alternativa mais segura:

const data = { id: 922337203685477580n }

JSON.stringify(data, (key, value) =>
  typeof value === "bigint" ? value.toString() : value
) // '{"id":"922337203685477580"}'

Conclusão

BigInt vs Number em JavaScript não é realmente uma competição — eles servem propósitos diferentes. Use Number para tudo que ele lida bem, que é a maioria das coisas. Recorra ao BigInt especificamente quando estiver trabalhando com inteiros que podem exceder 2⁵³ − 1 e onde a correção é inegociável. Essa é uma categoria estreita, mas importante, e o BigInt a trata exatamente da forma correta.

Perguntas Frequentes

O BigInt é suportado em todos os navegadores modernos, incluindo Chrome, Firefox, Safari e Edge. No entanto, o Internet Explorer não o suporta. Se você precisar dar suporte ao IE, precisará manter os valores como strings ou usar uma biblioteca de números grandes em vez de confiar no BigInt nativo.

Sim. Você pode comparar valores BigInt com outros BigInts usando operadores de comparação padrão como menor que, maior que e triplo igual. Você também pode usar igualdade frouxa para comparar um BigInt com um Number, então 10n == 10 retorna true, mas 10n === 10 retorna false porque são tipos diferentes.

Sim. As operações BigInt são geralmente mais lentas que as operações Number porque usam aritmética de precisão arbitrária em vez de instruções de hardware de tamanho fixo. Para a maioria das aplicações, a diferença é negligenciável, mas em loops críticos de desempenho ou caminhos quentes, você deve fazer benchmarks e preferir Number quando os valores permanecem dentro do intervalo de inteiros seguros.

Use o construtor Number, como Number(100n), que retorna 100. Tenha cuidado com valores grandes, porém. Se o BigInt exceder Number.MAX_SAFE_INTEGER, a conversão perderá precisão silenciosamente. Sempre verifique se o valor cabe dentro do intervalo seguro antes de converter.

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.