Pular para o conteúdo principal

Base64 vs Hex

Ambas são codificações de texto da RFC 4648 dos mesmos bytes — a diferença é aritmética e habitat. Hex dobra o tamanho, mas permanece alinhado ao nibble e sem padding, por isso domina checksums, endereços MAC e depuração. Base64 cresce os dados em um terço, e por isso domina o transporte em volume: MIME, JWTs, URIs data: e cookies.

Só local

Base64 vs Hex: explicação

As duas codificações parecem intercambiáveis: ambas transformam bytes arbitrários em texto imprimível, ambas decodificam sem perdas, e ambas são definidas lado a lado na RFC 4648. Elas não são tanto concorrentes quanto duas grafias com aritmética diferente — o hexadecimal dá a cada byte dois caracteres; o base64 empacota três bytes em quatro caracteres. Todo o resto desta página, do padding ao habitat, decorre dessa aritmética.

Os números, com precisão: hexadecimal é base16 — dezesseis caracteres, 4 bits cada — então um byte de 8 bits vira exatamente dois caracteres e os payloads crescem 100%. Base64 usa sessenta e quatro caracteres, 6 bits cada, e como o mínimo múltiplo comum de 8 e 6 é 24, três bytes viram quatro caracteres: uma sobrecarga de 33%, completada com padding de = sempre que a entrada não é múltiplo de três bytes.

Esta página transforma essa aritmética em decisões: uma tabela lado a lado, a matemática de tamanho com um exemplo resolvido, onde cada codificação virou convenção, e as armadilhas — padding, variantes de alfabeto, maiúsculas e minúsculas — que decodificadores rigorosos rejeitam. Os conversores abaixo alternam entre elas localmente, nada é enviado.

Para ver a diferença de tamanho no seu próprio payload, o conversor de Base64 para Hex recodifica-o localmente e mostra a contagem de caracteres dobrada.

Emagrecer uma string hex para transporte funciona do mesmo jeito — o conversor de Hex para Base64 empacota cada três bytes em quatro caracteres, inteiramente no seu navegador.

Os mesmos bytes, dois alfabetos

Ambas as codificações resolvem um problema: bytes são valores de 8 bits, mas transportes de texto — URLs, cabeçalhos, XML, JSON, e-mail — funcionam melhor com ASCII imprimível. Hex usa os dezesseis caracteres 0-9 e a-f; base64 usa A-Z, a-z, 0-9, + e /. Nenhuma das duas cifra ou comprime nada: ambas são especificadas publicamente, sem chave e instantaneamente reversíveis, e uma string base64 é proteção para o transporte, não segurança.

AspectoBase64Hexadecimal
Alfabeto64 caracteres: A-Z, a-z, 0-9, +, /16 caracteres: 0-9, a-f
Bits por caractere64
Sobrecarga de tamanho+33% — 4 caracteres por 3 bytes+100% — 2 caracteres por byte
Padding= preenche a saída até um múltiplo de 4Nenhum — um byte é sempre exatamente 2 caracteres
VariantesA forma URL-safe troca + e / por - e _Maiúsculas e minúsculas indiferentes por convenção
Domínios canônicosMIME, JWTs, URIs data:, cookiesChecksums, UUIDs, endereços MAC, dumps hex
PadrãoRFC 4648, seções 4 e 5RFC 4648, seção 8

A aritmética: um terço contra uma duplicação

Hex é alinhado ao nibble: um byte se divide em duas metades de 4 bits, cada uma renderizada como um caractere, então os comprimentos são previsíveis — um valor de n bytes tem sempre 2n caracteres, sem padding, sem casos de borda. Base64 reagrupa os bits em pedaços de 6 bits, e 24 bits é o primeiro ponto em que o mundo dos bytes e o mundo do base64 se alinham, então três bytes viram quatro caracteres. Um byte que sobra vira padding ==; dois que sobram viram um único =.

Um par resolvido torna a proporção concreta: os bytes de Hi são 48 69 em hex — quatro caracteres — e SGk= em base64 — também quatro caracteres, padding incluído. Em tamanhos reais, a diferença domina: um megabyte de dados vira aproximadamente 1.33 MB como base64 com padding, mas exatamente 2 MB como hex, e é por isso que os transportes em volume padronizaram no base64 enquanto valores curtos continuaram em hex.

Onde cada codificação vive

Base64 domina o volume e o transporte. MIME o usa para anexos de e-mail, a autenticação HTTP Basic codifica credenciais com ele, JWTs levam header, payload e assinatura em base64url, URIs data: incorporam imagens e fontes diretamente em páginas e folhas de estilo, e cookies carregam valores base64url porque + e / se comportam mal em URLs e cabeçalhos. Onde quer que binário precise sobreviver a um cano só de texto com o mínimo de custo, base64 é a resposta.

Hex domina o pequeno e o conferido por humanos. Resumos criptográficos são impressos em hex por convenção — saída de SHA-256, identificadores de commit do git — porque pares de largura fixa, sem padding e alinhados ao byte são triviais de comparar a olho ou em voz alta. Endereços MAC, a forma textual de UUID e cores CSS como #RRGGBB são todos hex, e editores hex, dumps de memória e depuradores de protocolo o usam porque cada byte se lê como uma unidade autocontida.

Armadilhas e quando escolher cada um

As armadilhas do Base64 estão todas no alfabeto. As variantes padrão e URL-safe diferem em dois caracteres e jamais devem ser misturadas; o padding é exigido por decodificadores rigorosos, mas removido pela convenção de JWT; a saída diferencia maiúsculas de minúsculas; e o MIME quebra linhas a cada 76 caracteres. Hex tem exatamente uma: o caso. Minúsculas são a convenção e maiúsculas aparecem em algumas ferramentas, mas misturá-las é questão cosmética — todo decodificador rigoroso aceita qualquer uma.

Resumindo: escolha base64 quando o volume importa ou um protocolo exige — anexos, tokens, binário incorporado. Escolha hex para valores curtos que humanos vão comparar, copiar ou depurar: resumos, identificadores, cores. A escolha se inverte o tempo todo em sistemas reais — um JWT chega em base64url e o fingerprint SHA-256 dele é hex — e os conversores abaixo tratam essa travessia no seu navegador.

Perguntas frequentes

Qual é mais compacto, base64 ou hex?

Base64, sempre e exatamente. Hex escreve 2 caracteres por byte; base64 escreve 4 caracteres por 3 bytes, então, para a mesma entrada, a saída base64 tem dois terços do comprimento do hex. Concretamente, um megabyte de dados vira cerca de 1.33 MB como base64 com padding, contra exatamente 2 MB como hex.

Base64 é criptografia, ou esconde alguma coisa?

Não — nenhuma das codificações dá sigilo. Ambas são transformações sem chave, especificadas publicamente, que qualquer um reverte instantaneamente: uma string base64 de uma senha decodifica para essa senha em qualquer lugar. Elas resolvem transporte, não confidencialidade — dados binários sobrevivendo a um canal só de texto. Para sigilo você precisa de criptografia, depois da qual o texto cifrado ainda pode ser codificado em base64 para transporte.

Os conversores de base64 e hex enviam meus dados?

Não. Codificar, decodificar e converter: tudo roda dentro da sua aba do navegador; não há endpoint de envio, e a Content-Security-Policy do site só permite requisições de rede para ele mesmo. Observe o painel Network do DevTools enquanto converte e você não verá requisições para fora — payloads, incluindo segredos colados por engano, nunca saem da aba.

Por que hashes e checksums aparecem em hex?

Convenção endurecida pela mecânica. A saída hex tem largura fixa, não precisa de padding, e os dois caracteres de cada byte se enfileiram, então comparações e diffs se alinham visualmente; um alfabeto todo alfanumérico sobrevive a copiar e colar, a logs e a CSVs. Toda ferramenta, do openssl ao git, imprime resumos em hex, então hex é o que as pessoas aprenderam a ler.

O que é base64url e quando ele é necessário?

A variante URL-safe da RFC 4648, seção 5: o menos e o sublinhado substituem o mais e a barra, porque + lê como um espaço na codificação de formulários e / quebra segmentos de caminho. JWTs, cookies e parâmetros de query o usam para que tokens sobrevivam intactos a URLs. Decodificadores devem aceitar ambos os alfabetos; os rigorosos rejeitam um misturado.

Por que o base64 às vezes termina em = ou ==?

Padding. A saída base64 deve ser múltiplo de quatro caracteres, e quando a entrada não é múltiplo de três bytes, um ou dois caracteres = preenchem o grupo final: um byte que sobra acrescenta ==, dois acrescentam um único =. Hex nunca precisa de padding, já que dois caracteres por byte sempre dividem de forma exata.

Onde posso ler os padrões citados aqui?

  • RFC 4648 — As codificações de dados Base16, Base32 e Base64