Pular para o conteúdo principal
ToolsByUs

Hexadecimal para Base64

Este conversor re-codifica uma string hexadecimal como Base64 padrão no seu navegador. A entrada não diferencia maiúsculas de minúsculas, prefixos 0x e espaços soltos são removidos, e a saída segue a RFC 4648 com preenchimento. Entrada de comprimento ímpar é rejeitada de plano: um nibble faltante nunca é adivinhado. Nada é enviado.

Só local

Hexadecimal para Base64: explicação

Hex é a forma como programadores escrevem bytes; Base64 é a forma como a rede os lê. Este conversor lê uma string hexadecimal par por par de bytes e re-codifica os mesmos bytes no alfabeto padrão da RFC 4648, com preenchimento — a string exata que um codificador adequado emitiria para os dados subjacentes, pronta para um cabeçalho, um arquivo de configuração ou um campo de token.

Hex do mundo real é desorganizado, e o conversor se adapta: dígitos maiúsculos e minúsculos são iguais, prefixos 0x são removidos onde quer que apareçam, e espaços soltos — despejos de coluna, pares espaçados, quebras de linha — são limpos antes da análise. O que ele não faz é adivinhar. Um número ímpar de dígitos hexadecimais significa que um nibble está faltando em algum lugar, e o conversor recusa-se a inventar onde.

A conversão é inteiramente local, como em todo este site: sua string é analisada e codificada nesta aba do navegador, nenhuma requisição é feita, e a Content-Security-Policy da página proíbe conexões de saída. O painel de Rede permanecendo vazio enquanto você converte é a prova, verificável em segundos.

Verificar a resposta na mão é fácil na direção oposta: alimente o resultado no conversor Conversor de Base64 para Hex e você deve obter sua string hexadecimal original de volta, byte por byte.

Escolher entre as duas codificações desde o início é o tema do Comparação Base64 vs hex do site, que compara tamanho, legibilidade e adequação ao protocolo sem o folclore tribal.

Como a conversão realmente funciona

A regra de agrupamento do Base64 faz todo o trabalho real, e vale a pena ver uma vez, porque explica tanto o comprimento quanto o preenchimento de tudo que esta ferramenta emite:

  • Limpeza: prefixos 0x e 0X são removidos, todo espaço em branco é eliminado, e os caracteres restantes devem ser 0–9, a–f ou A–F; qualquer outra coisa é um erro nomeado com sua posição.
  • Par: dois dígitos hexadecimais se tornam um byte — 48 é o byte 0x48, a letra H.
  • Grupo: bytes são pegados três de cada vez; cada trio de 24 bits é dividido em quatro valores de 6 bits, e cada valor mapeia para um caractere do alfabeto RFC 4648 A–Z a–z 0–9 + /.
  • Preenchimento: um grupo final de 1 ou 2 bytes é completado com caracteres = para que o comprimento da saída seja sempre múltiplo de 4.

A entrada é limpa, não julgada

Hex na natureza chega decorado. Resumos de hash vêm com prefixo 0x de algumas bibliotecas; despejos de pacote chegam como colunas de pares espaçados; documentação escreve 48 65 6C com maiúsculas enquanto um log impresso tem 48656l em minúsculas. Tudo isso são os mesmos bytes, então o conversor trata da mesma forma: prefixos e espaços em branco vão, a parada de maiúsculas/minúsculas não importa, e só após a limpeza o analisador insiste em dígitos hexadecimais. Caso misto em uma mesma string — 6C ao lado de 6c — é aceitável, porque as duas grafias denotam um valor de nibble.

Entrada de comprimento ímpar: a política explícita

Uma string hexadecimal de comprimento ímpar não pode ser analisada sem adivinhar, porque um dígito está faltando e qualquer extremidade é um lugar plausível para a perda. Adicionar um zero no início e no final produz bytes diferentes — 0x48 versus 0x84 — então corrigir silenciosamente a entrada escolheria um significado ao acaso e entregaria dados que parecem corretos. A política deste conversor é recusar: uma entrada de comprimento ímpar retorna um erro nomeado informando o comprimento, e o reparo pertence a quem sabe onde o dígito realmente foi perdido. É a mesma regra de recusar-em vez-de-distortor que os outros conversores deste site aplicam.

Como a saída parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” produz: uma string hexadecimal decorada — prefixo 0x, espaços, caso misto — chegando como cinco bytes que escrevem "Hello" e saindo como o Base64 padrão SGVsbG8=, com um = porque o grupo final carrega dois bytes em vez de três. A saída usa o alfabeto padrão, mais e barra inclusos, não a variante segura para URL; se seu destino distorce esses dois caracteres, o alfabeto seguro para URL da RFC 4648 é a substituição documentada para aplicar depois.

Perguntas frequentes

Converter hex para Base64 envia minha entrada para algum lugar?

Não. A análise e codificação são executadas dentro desta aba do navegador, em código que veio com a página. A página não define um endpoint de envio, e sua Content-Security-Policy bloqueia conexões de saída, então a exfiltração é estruturalmente impossível, não apenas prometida. DevTools torna a afirmação verificável: abra o painel Rede, converta uma string, e veja que ele registra nada.

Por que hex de comprimento ímpar é rejeitado em vez de ser corrigido?

Porque cada correção é uma adivinhação com consequências reais. Uma contagem ímpar de dígitos significa que um nibble está faltando, e preencher com um zero na frente versus atrás produz bytes diferentes — 48 versus 84 — então um reparo silencioso inventaria dados que parecem plausíveis. O conversor retorna um erro nomeado com o comprimento, e você corrige a fonte onde o dígito foi realmente perdido.

Letras maiúsculas, prefixos 0x e espaços são realmente aceitos?

Sim. A parada de maiúsculas/minúsculas é irrelevante — 4C e 4c são o mesmo nibble — prefixos 0x e 0X são removidos mesmo quando repetidos antes de cada byte, e todo espaço em branco é removido antes da análise, então um despejo hexadecimal colado convertido sem limpeza prévia. Após a limpeza, apenas 0–9 e a–f ou A–F são válidos; um g solto ou uma vírgula é um erro nomeado com sua posição.

A saída sempre inclui preenchimento =?

Preenchimento aparece apenas quando a contagem de bytes não é múltiplo de três — um = para um resto de dois bytes, dois para um resto de um byte — e o comprimento da saída é sempre múltiplo de 4. Os caracteres = são parte da RFC 4648, não ruído: removê-los quebra decodificadores que dependem do comprimento. Esta ferramenta emite a forma padrão preenchida, correspondendo ao que codificadores padrão produzem.

Por que a saída em Base64 é menor que a entrada em hex?

Cálculo de sobrecarga de codificação: hex gasta 2 caracteres por byte, Base64 gasta 4 a cada 3. Para os mesmos bytes, hex roda a 100 por cento de sobrecarga e Base64 a cerca de 33, então um resumo de 64 bytes cai de 128 dígitos hexadecimais para 88 caracteres Base64 incluindo preenchimento. Os dados são idênticos durante todo o processo — apenas a eficiência de empacotamento do alfabeto mudou.

Codificação em Base64 é uma forma de criptografar dados?

Não, e tratá-la como uma é um erro de segurança genuíno. Base64 é uma codificação reversível sem chave: qualquer pessoa que tiver a string pode decodificá-la, offline, em milissegundos — esta página faz sem rede. Ela existe para mover bytes por canais seguros para texto, não para protegê-los. Se a confidencialidade importa, criptografe primeiro, depois aplique Base64 no ciphertext para transporte.

Equipe ToolsByUs · Como verificamos nossas ferramentas