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.
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.
| Aspecto | Base64 | Hexadecimal |
|---|---|---|
| Alfabeto | 64 caracteres: A-Z, a-z, 0-9, +, / | 16 caracteres: 0-9, a-f |
| Bits por caractere | 6 | 4 |
| Sobrecarga de tamanho | +33% — 4 caracteres por 3 bytes | +100% — 2 caracteres por byte |
| Padding | = preenche a saída até um múltiplo de 4 | Nenhum — um byte é sempre exatamente 2 caracteres |
| Variantes | A forma URL-safe troca + e / por - e _ | Maiúsculas e minúsculas indiferentes por convenção |
| Domínios canônicos | MIME, JWTs, URIs data:, cookies | Checksums, UUIDs, endereços MAC, dumps hex |
| Padrão | RFC 4648, seções 4 e 5 | RFC 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
Quais ferramentas relacionadas devo usar a seguir?
- Base64 para hexadecimalConversor que roda no seu navegadorAbrir
- Hexadecimal para Base64Conversor que roda no seu navegadorAbrir
- Codificar e decodificar Base64Codifica e decodifica Base64 padrão e URL-safeAbrir
- Como funciona o Base64Guia em linguagem simplesAbrir
- UUID vs NanoIDComparação lado a ladoAbrir
- Ferramentas de codificaçãoBase64, codificação de URL, hashes e inspeção de tokens.Abrir