Como a Codificação Base64 Funciona (e Por Que Não É Criptografia)

O que o Base64 realmente faz no nível dos bits

O Base64 converte 3 bytes de entrada em 4 caracteres de saída reparticionando 24 bits em quatro grupos de 6 bits cada. Um byte contém 8 bits, então três bytes dão 24 bits; 24 se divide de forma exata por 6, produzindo quatro números de 6 bits que variam de 0 a 63. Cada um desses números é um índice em um alfabeto de 64 caracteres: A–Z (0–25), a–z (26–51), 0–9 (52–61) e dois símbolos para 62 e 63.

Pegue os três bytes ASCII de "Man": M=77, a=97, n=110, que em binário são 01001101 01100001 01101110. Concatenada, essa string de 24 bits se reagrupa como 010011 010110 000101 101110, ou os valores decimais 19, 22, 5, 46. Indexando o alfabeto, obtemos T, W, F, u, então "Man" se codifica como "TWFu". A transformação é puramente mecânica e sem perdas.

O overhead de 33% é a estatística que define o formato: 4 bytes de saída para cada 3 bytes de entrada é uma razão de 4/3, um aumento de 33,3% antes de qualquer preenchimento com quebras de linha. A codificação MIME padrão acrescenta uma pequena penalidade adicional ao inserir uma quebra de linha a cada 76 caracteres, empurrando o overhead do mundo real para um pouco acima de 33%.

Por que o Base64 NÃO é criptografia nem segurança

O Base64 é uma codificação, não criptografia, porque não usa nenhuma chave e qualquer um consegue decodificá-lo instantaneamente com um algoritmo público e padronizado. A criptografia transforma os dados de modo que apenas quem tem a chave correta consiga recuperá-los; o Base64 transforma os dados de modo que qualquer dispositivo na Terra consiga recuperá-los, que é exatamente o objetivo oposto. Tratar uma string Base64 como um segredo é um erro de segurança clássico.

A confusão surge porque a saída do Base64 parece ilegível para humanos, só letras e dígitos com o eventual +, / ou =. Mas ilegível-para-um-humano não é o mesmo que protegido. Um único comando como `base64 -d` na linha de comando, ou um trecho de duas linhas em qualquer linguagem, devolve os bytes originais sem exigir nenhuma credencial.

A regra a lembrar: nunca armazene senhas, chaves de API, tokens ou dados pessoais em Base64 achando que isso esconde algo. O Base64 torna os dados binários seguros para serem transportados por canais exclusivamente de texto; ele não torna nada seguro contra olhos curiosos. Se você precisa de confidencialidade, precisa de criptografia de verdade, como o AES, aplicada antes de você codificar o texto cifrado em Base64 para o transporte.

O preenchimento =, os caracteres +/ e a variante Base64URL

O caractere = é o preenchimento que sinaliza quantos bytes faltaram no grupo final, e ele aparece apenas no fim de uma string Base64. Quando o comprimento da entrada não é um múltiplo de 3, o último grupo contém 1 ou 2 bytes em vez de 3; o codificador preenche os bits faltantes com zeros e acrescenta um = (para um resto de 2 bytes) ou dois == (para um resto de 1 byte), de modo que o comprimento da saída permaneça um múltiplo exato de 4.

O Base64 padrão usa + e / para os valores 62 e 63, mas esses caracteres são inseguros em URLs e nomes de arquivo: o + pode ser interpretado como um espaço em strings de consulta, e o / é um separador de caminho. O Base64URL, definido na RFC 4648, os troca por - e _ respectivamente e geralmente omite o preenchimento =, para que um token possa trafegar dentro de uma URL ou nome de arquivo sem alterações. Os JSON Web Tokens usam o Base64URL exatamente por essa razão.

A tabela abaixo compara as três variantes que você vai encontrar na prática.

Quando usar o Base64 e quando não usar

Use o Base64 sempre que dados binários precisarem passar por um canal que só carrega texto de forma confiável: imagens embutidas como data URIs em CSS ou HTML, blobs binários dentro de payloads JSON, anexos de e-mail e os segmentos codificados dos JSON Web Tokens. Em cada caso, a alternativa, enviar os bytes brutos, seria corrompida ou rejeitada por sistemas que presumem texto.

Evite o Base64 para arquivos grandes, porque a penalidade de 33% de tamanho é paga em cada byte. Codificar uma imagem de 10 MB produz cerca de 13,3 MB de texto, que depois precisa ser transferido, analisado e decodificado. Para qualquer coisa volumosa, envie o arquivo bruto por um transporte que lide com binário, como um upload multipart normal ou uma URL assinada, e reserve o Base64 para pequenos ativos, ícones e metadados.

Um segundo custo é a CPU e a memória: codificar e decodificar strings grandes não é de graça, e embutir data URIs grandes impede o cache do navegador, já que os bytes são baixados de novo a cada página que os inclui, em vez de armazenados em cache uma única vez como um arquivo separado.

É seguro codificar arquivos com privacidade no navegador?

Sim, a codificação Base64 em uma ferramenta web moderna acontece inteiramente de forma local no seu navegador, então os bytes do seu arquivo nunca são enviados a nenhum servidor. A codificação é pura matemática, o `btoa()` e a FileReader API rodam no seu próprio dispositivo, o que significa que uma ferramenta no lado do cliente consegue converter um documento ou imagem para Base64 sem uma ida e volta pela rede.

Isso importa quando a entrada é sensível, uma chave privada, um documento interno, uma imagem de cliente, porque um codificador puramente no lado do cliente oferece a conveniência de uma interface web com a privacidade de uma ferramenta de linha de comando offline. Nada sai da máquina em que você está trabalhando.

Perguntas frequentes