Pular para o conteúdo principal
ToolsByUs

Base64 para hexadecimal

Este conversor decodifica Base64 conforme RFC 4648 e re-codifica os mesmos bytes como hexadecimal minúsculo no seu navegador. O preenchimento é tratado, o alfabeto seguro para URL é aceito e cada byte mapeia para exatamente dois dígitos hexadecimais na ordem de saída: sem prefixos, sem separadores, sem envio.

Só local

Base64 para hexadecimal: explicação

Base64 e hex são duas maneiras de escrever os mesmos bytes, e este conversor faz a conversão entre eles: decodifica o Base64 exatamente como prescreve a RFC 4648, então imprime cada byte decodificado como dois dígitos hexadecimais minúsculos. Nada é reinterpretado no meio — o que você obtém é a sequência de bytes que um editor hexadecimal mostraria, caractere por caractere.

As partes interessantes são aquelas que conversores geralmente pulam. Preenchimento: os caracteres = no final são tratados, e entrada cujo preenchimento um pipeline removeu também é aceita. Alfabetos: o conjunto padrão A–Z a–z 0–9 + / é decodificado, e a variante -_ segura para URL definida pela mesma RFC é normalizada antes da decodificação. Ordem de bytes: preservada — um byte para dois dígitos hexadecimais, nibble alto primeiro, sempre.

Como toda ferramenta deste site, a conversão roda nesta aba do navegador: seu texto nunca sai da máquina, nenhuma requisição é feita, e a Content-Security-Policy do site proíbe a página de se conectar a qualquer lugar. Ver o painel Network do DevTools vazio enquanto você converte é a prova, não a promessa.

A viagem de volta — bytes mostrados como hex, indo para um cabeçalho ou campo de token — é o que a ferramenta irmã conversor de Hex para Base64 realiza, com o mesmo alfabeto RFC 4648 e o mesmo processamento local.

Se as regras de agrupamento e preenchimento parecem arbitrárias, o guia sobre como o Base64 realmente funciona constrói todo o mecanismo a partir dos primeiros princípios em três parágrafos curtos.

Como a conversão realmente funciona

A conversão tem duas etapas bem definidas com nada escondido entre elas, e cada etapa tem uma política que você pode cobrar:

  • Normalizar: espaços em branco, quebras de linha (entrada com MIME) e um ? inicial são removidos; os caracteres URL-safe - e _ são mapeados para + e / conforme o segundo alfabeto da RFC 4648.
  • Decodificar: os caracteres restantes mapeiam através do alfabeto RFC 4648 — 4 caracteres para 3 bytes — com = preenchimento consumido no último quantum.
  • Validar: qualquer caractere fora do alfabeto é um erro nomeado com sua posição; um comprimento de que é um múltiplo de 4 mais 1 é rejeitado imediatamente, porque um caractere solitário não pode formar um byte inteiro.
  • Emitir: cada byte se torna dois dígitos hexadecimais minúsculos, nibble alto primeiro, concatenados sem separadores e sem prefixo 0x.

Preenchimento e alfabetos, precisamente

O alfabeto padrão da RFC 4648 é A–Z, a–z, 0–9, + e /, com = preenchendo o último quantum sempre que a contagem de bytes não for múltiplo de 3. O preenchimento é significativo — ele desambigua um último quantum de um byte de dois — mas o decodificador também aceita entrada sem preenchimento quando o comprimento torna o quantum inequívoco (comprimentos de 2 ou 3 mod 4). Um comprimento de 1 mod 4 é inválido com ou sem preenchimento — um caractere Base64 não pode gerar um byte inteiro — e é rejeitado em vez de preenchido com zero.

A variante segura para URL definida pela mesma RFC — hífen e sublinhado no lugar de mais e barra — é aceita e normalizada, o que importa na prática porque JWTs e parâmetros de URL geralmente são emitidos sem preenchimento e seguros para URL. Misturar ambos os alfabetos em uma entrada é rejeitado: uma string contendo ambos + e - não tem leitura coerente.

Como é a saída

O exemplo abaixo é o par exato que o botão “Carregar exemplo” produz: o Base64 para "Hello world" renderizado como 22 dígitos hexadecimais minúsculos — dois por byte, onze bytes. A saída é uma string contínua — sem prefixo 0x, sem espaços, quebras de linha — porque editores hexadecimais, dissecares e código preferem a forma simples. A aritmética de comprimento: Base64 gasta 4 caracteres por 3 bytes, hex gasta 2 por byte, então hex sai cerca de 1,5 vezes o comprimento do Base64 sem preenchimento — uma propriedade das codificações, não dos seus dados.

Ordem de bytes, declarada uma vez

Endianness nunca entra em cena, e vale a pena dizer por quê. Base64 decodifica para uma sequência de bytes, e uma sequência tem uma ordem natural: primeiro byte decodificado primeiro. A saída hexadecimal espelha exatamente essa ordem — byte n se torna os caracteres hexadecimais nas posições 2n e 2n+1 — então o resultado é a mesma string que um editor hexadecimal sem offsets exibiria. Não há troca de palavras, nenhuma reinterpretação little-endian, e nenhuma surpresa quando você diff contra xxd.

Perguntas frequentes

Converter Base64 para hex envia meus dados para algum lugar?

Não. Decodificação e re-codificação acontecem dentro desta aba do navegador, em JavaScript que carregou com a página. Não há rota de envio no código da página, e a Content-Security-Policy do site proíbe conexões de saída. Para verificar você mesmo: abra DevTools, limpe ou monitore o painel Network, converta e observe que nenhuma requisição aparece — a ferramenta funciona com o cabo de rede desconectado.

A saída hexadecimal é maiúscula ou minúscula?

Minúscula, sempre — a mesma convenção que xxd e a maioria dos editores hexadecimais imprimem. Maiúsculas e minúsculas em hex denotam bytes idênticos, e uma passagem de case-folding é sem perdas se um sistema exigir maiúsculas. A saída não tem prefixo 0x, separadores ou quebras de linha, então cola limpa em código, dissecares e testes.

Por que a string hexadecimal é mais longa que a entrada Base64?

Aritmética das duas codificações: Base64 empacota 3 bytes em 4 caracteres (cerca de 33% de sobrecarga), enquanto hex gasta 2 caracteres em cada byte (100% de sobrecarga). Dividindo as duas, hex sai cerca de 1,5 vezes o comprimento do Base64 sem preenchimento para os mesmos bytes. Nenhuma codificação comprime nada — ambas são apenas alfabetos sobre a mesma sequência de bytes.

A entrada precisa do seu preenchimento =?

Não. Entrada preenchida é decodificada como está, e preenchimento que algum pipeline removeu é reconstruído a partir do comprimento — um comprimento de 2 ou 3 mod 4 identifica o último quantum inequivocamente. O único comprimento que é sempre inválido é 1 mod 4, com ou sem preenchimento, porque um caractere Base64 não pode gerar um byte inteiro; essa entrada é rejeitada com um erro claro, nunca adivinhada.

Converter Base64 para hex é uma forma de descriptografia?

Não, e a distinção importa. Ambos Base64 e hex são codificações: escritas reversíveis dos mesmos bytes sem nenhuma chave em qualquer lugar do processo. qualquer pessoa pode decodificar ambos, incluindo esta página, offline. Se seu Base64 codificava texto cifrado, convertê-lo para hexadecimal muda apenas a representação — os dados são exatamente tão legíveis, ou tão protegidos, quanto antes.

E o Base64 seguro para URL com caracteres - e _?

Aceito e tratado. RFC 4648 define o alfabeto seguro para URL — hífen para mais, sublinhado para barra — para contextos onde + e / seriam corrompidos, como JWTs e segmentos de caminho URL. O conversor normaliza esses caracteres para o alfabeto padrão antes de decodificar, então um token copiado direto de um cabeçalho Authorization funciona sem modificações. Apenas uma mistura de ambos os alfabetos é recusada.

Equipe ToolsByUs · Como verificamos nossas ferramentas