Conversor de bases numéricas

O mesmo número, escrito de outro jeito

Uma base é só a quantidade de símbolos que a escrita usa. O decimal tem dez (0 a 9); o binário, dois (0 e 1); o octal, oito; o hexadecimal, dezesseis (0 a 9 e A a F). O número não muda: 255, 11111111, 377 e FF são o mesmo valor. O que muda é o quanto a escrita ajuda em cada uso. O hexadecimal agrupa quatro bits em cada dígito, e por isso aparece em cores (#FF8800), endereços de memória e identificadores; o binário mostra bit a bit, e serve para máscaras e permissões; o octal agrupa três bits e sobrevive nas permissões de arquivo do Unix (chmod 755).

Por que a conversão precisa ser exata

O Number do JavaScript é um ponto flutuante de 64 bits e só guarda inteiros sem erro até 2⁵³ − 1, que é 9.007.199.254.740.991. Acima disso ele arredonda para o valor representável mais próximo. Um conversor feito com Number e toString(16) acerta tudo que se digita numa aula e erra, em silêncio, o que um programador precisa: o maior inteiro de 64 bits sem sinal, 18.446.744.073.709.551.615, sai em hexadecimal como 10000000000000000 — um dígito a mais, e outro número — em vez de FFFFFFFFFFFFFFFF.

Para ver se isso acontece de verdade, digitei dois números no campo decimal de cinco páginas brasileiras de conversão em 5 de outubro de 2026: o primeiro inteiro depois do limite, 9.007.199.254.740.993, e o maior de 64 bits, 18.446.744.073.709.551.615. O hexadecimal certo é, respectivamente, 20000000000001 e FFFFFFFFFFFFFFFF. Foi isto que cada uma mostrou:

Três páginas devolveram, caractere por caractere, o que um Number do JavaScript devolveria para esse texto — e essa coincidência é tudo que se pode afirmar delas, porque não li o código de nenhuma. Uma quarta converteu outro número: o campo decimal dela ficou só com os 13 primeiros dígitos que digitei. A quinta devolveu a página de erro do servidor nas duas tentativas, embora tenha respondido certo com 255. É uma amostra de cinco páginas, numa data, e qualquer uma pode ter mudado depois. Uma sexta diz, no texto dela, usar BigInt; não a medi com o mesmo rigor e não faço nenhuma afirmação sobre ela.

Esta página usa BigInt do começo ao fim: o texto vira um inteiro de precisão arbitrária, e a escrita em cada base sai desse inteiro. O teste automático confere a conversão contra vetores gerados por um programa independente, em sete bases, até 128 bits.

Onde isso aparece na vida real

Identificadores de 64 bits (o BIGINT de banco de dados, os “snowflake” de redes sociais), máscaras de bits e hashes de 64 bits passam de 2⁵³ com facilidade. Um aviso que vale antes de colar um número aqui: se ele chegou por JSON.parse ou por uma planilha, já pode ter sido arredondado antes — o JSON lido pelo JavaScript passa pelo mesmo Number. Se os últimos dígitos do ID estão estranhos (muitos zeros), o problema está antes desta página.

O que a ferramenta aceita

Prefixos 0x, 0b e 0o na frente (e a página avisa quando trocou a base por causa deles), sinal de menos, espaço ou sublinhado entre grupos de dígitos (1111 0000, 1_000_000) e o ponto de milhar do decimal em grupos de três (18.446.744.073.709.551.615). Em hexadecimal, 0b1 é o número B1 e não um prefixo binário: a letra só vira prefixo quando não pode ser dígito da base escolhida.

Número negativo aparece com o sinal de menos, e não em complemento de dois, que depende de um tamanho de palavra que ninguém disse. E a ferramenta converte só inteiros: um ponto ou uma vírgula é recusado com a razão, e não lido como 1 — 0,1 decimal é uma dízima infinita em binário, e isso é outra conta.

int8, uint32, int64: onde o número cabe

Embaixo do resultado a página diz quantos bits o número ocupa e o menor tipo inteiro em que ele cabe, com e sem sinal. É a leitura que se faz antes de escolher um tipo de coluna ou de variável: o maior de 64 bits sem sinal cabe em uint64 e em nenhum tipo com sinal.

O que eu digito sai do meu computador?

Não. A conta inteira roda no seu navegador. Nenhuma requisição leva o que você digita, e nada fica guardado depois que você fecha a aba.