Codificador e Decodificador Base64

Para que serve o Base64

O Base64 reescreve bytes arbitrários usando 64 caracteres que sobrevivem a qualquer canal de texto. Ele pega três bytes por vez, divide esses 24 bits em quatro grupos de seis e associa cada grupo a um caractere entre A-Z, a-z, 0-9 e dois símbolos. Saem quatro caracteres para cada três bytes que entram, então o resultado fica cerca de 33% maior que o original, sem contar quebras de linha.

O objetivo é transporte, não sigilo. O Base64 foi criado para canais que estragam bytes brutos: sistemas de e-mail que cortam o bit mais alto, protocolos que tratam certos caracteres de controle como comandos, formatos que precisam ser texto puro. Não é criptografia nem compressão, e qualquer coisa codificada pode ser lida trivialmente por quem quiser decodificar. Tratar uma string Base64 como se estivesse protegida é um mal-entendido, e este decodificador torna isso fácil de demonstrar.

Padding e os dois alfabetos

Quando a entrada não se divide exatamente em grupos de três bytes, a saída recebe um ou dois caracteres = de padding para que o tamanho seja múltiplo de quatro. Alguns geradores omitem o padding, e este decodificador o recoloca em vez de rejeitar a entrada, já que a quantidade correta é dada pelo tamanho.

O alfabeto padrão termina em + e /, que têm significado numa URL e viram %2B e %2F depois do escape, algo feio e propenso a erros numa query string ou num nome de arquivo. Por isso a seção 5 da RFC 4648 define uma variante segura para URL que usa - e _, normalmente sem padding, já que o = também precisa de escape. É a variante que os JWTs usam em todos os segmentos. Na codificação você pode escolher qualquer uma; na decodificação a ferramenta detecta qual alfabeto você colou, sem precisar informar.

Unicode e a armadilha do btoa

Os navegadores têm a função btoa embutida há décadas, e ela não faz o que a maioria imagina. Ela trabalha com Latin-1: todo caractere da entrada precisa ter code point abaixo de 256, e qualquer outro gera InvalidCharacterError. Passe um único caractere japonês, um nome em cirílico ou um emoji e ela falha na hora.

A primeira solução que as pessoas encontram é aplicar escape na string antes de codificar, o que transforma tudo fora do ASCII numa sequência de bytes diferente, que vira lixo quando decodificada do outro lado. O jeito certo, e o usado aqui, é converter o texto em bytes UTF-8 com o TextEncoder primeiro e codificar esses bytes. É por isso que qualquer sistema de escrita faz a ida e volta nesta ferramenta sem alteração.

A decodificação faz o caminho inverso e se recusa a adivinhar. Se os bytes decodificados não forem UTF-8 válido, você é avisado de que são binários, em vez de ver uma string cheia de caracteres de substituição. Isso normalmente significa que o conteúdo é uma imagem, um arquivo compactado, uma mensagem protobuf ou um texto cifrado, e o certo é salvar os bytes, não lê-los como texto.

Quando não usar

Base64 é a ferramenta errada para guardar segredos, porque não protege nada. Também é uma má escolha padrão para embutir arquivos grandes: um data URI de imagem aumenta o tamanho em um terço, não pode ser armazenado em cache separadamente do documento que o contém e trava a página enquanto é processado.

Onde ele vale a pena é nos casos pequenos e incômodos: um certificado em formato PEM, uma assinatura, um campo binário dentro de um corpo JSON, um ícone curto embutido, um segmento de token.

Três bytes entram, quatro caracteres saem

A codificação fica mais fácil de confiar depois que você a faz à mão uma vez. Pegue as três letras ASCII de Man: seus valores de byte são 77, 97 e 110, que em binário são 01001101, 01100001 e 01101110. Escreva esses 24 bits em sequência e corte-os em quatro grupos de seis, em vez de três grupos de oito: 010011, 010110, 000101, 101110. Leia cada grupo como número - 19, 22, 5, 46 - e procure no alfabeto A-Z, a-z, 0-9, + e /, em que o índice 0 é A e o índice 26 é a. O resultado é TWFu.

Toda propriedade do Base64 sai dessa aritmética. Seis bits por caractere é por que o alfabeto tem exatamente 64 entradas. Quatro caracteres a cada três bytes é por que a saída fica um terço maior. E o padding existe porque o último grupo pode ficar incompleto: um byte sobrando produz dois caracteres mais ==, dois bytes sobrando produzem três caracteres mais =.

Decodificar é a mesma operação ao contrário, e é por isso que qualquer string Base64 cujo tamanho não seja múltiplo de quatro está padronizada com preenchimento, truncada, ou foi produzida por um codificador que removeu o padding de propósito.

Onde você encontra isso em sistemas reais

Arquivos PEM - certificados, CSRs, chaves privadas - são Base64 com uma linha de cabeçalho e outra de rodapé e uma quebra de linha a cada 64 caracteres. Esse comprimento de linha é uma convenção do MIME, e não algo que o Base64 exija, e espera-se que os decodificadores ignorem as quebras.

A autenticação HTTP Basic envia usuario:senha codificado em Base64 no cabeçalho Authorization, que é exatamente por que Basic auth sobre HTTP puro equivale a enviar a senha em texto claro. Anexos de e-mail usam Base64 desde que o MIME foi definido, em 1992, pelo motivo original: não se podia confiar bytes arbitrários aos servidores de e-mail da época.

Data URIs embutem um arquivo inteiro num documento - data:image/png;base64, seguido do conteúdo - e APIs JSON usam Base64 sempre que um campo precisa carregar bytes, já que JSON não tem tipo binário. Os segmentos de um JWT usam a variante segura para URL sem padding, e a configuração do Docker, os secrets do Kubernetes e muitos sistemas de CI guardam credenciais codificadas em Base64, o que é armazenamento, não proteção.

Tamanho, memória e arquivos grandes

A expansão de 33% é o custo mais visível e normalmente o menor. Texto Base64 comprime pior do que os bytes de origem, porque a codificação destrói padrões de byte que um compressor aproveitaria, então um payload Base64 comprimido com gzip costuma ser maior que o original comprimido.

No navegador, a memória é a restrição mais séria. Codificar um arquivo significa manter os bytes e a string resultante ao mesmo tempo, e a string é um terço maior, então um arquivo de 100 MB pode precisar de várias centenas de megabytes antes que qualquer coisa seja enviada. APIs de streaming - ler o arquivo em pedaços e codificar cada um - evitam isso, desde que cada pedaço seja múltiplo de três bytes para que o padding só apareça no final.

Para qualquer coisa grande, a melhor resposta normalmente é não codificar: envie o arquivo como multipart form data ou como corpo bruto, e deixe o Base64 para os valores pequenos e incômodos que precisam viajar dentro de um formato de texto.

Os alfabetos aparentados e por que existem

Base32 usa 32 caracteres e produz uma saída 60% maior que a entrada, o que parece uma troca ruim até você precisar de algo que uma pessoa consiga ler em voz alta ou digitar. Não diferencia maiúsculas de minúsculas, evita caracteres facilmente confundidos, e é o que segredos TOTP e endereços onion usam.

Base58 descarta 0, O, I, l e os dois símbolos para que uma string possa ser copiada a olho sem ambiguidade; endereços de Bitcoin são o uso mais conhecido. Base85, ou Ascii85, empacota quatro bytes em cinco caracteres e é mais denso que o Base64, ao custo de usar pontuação que muitos formatos precisariam escapar - e é por isso que ele sobrevive principalmente dentro de PDF e PostScript.

O padrão é consistente: todos eles trocam densidade pelas restrições do canal. O Base64 está onde está porque é denso o bastante para valer o trabalho e seguro na maior variedade de canais de texto.

Investigando um payload que caiu na sua mão

Uma primeira pergunta útil sobre qualquer string opaca é se aquilo é Base64. Três sinais são confiáveis: o comprimento é múltiplo de quatro ou termina em um ou dois sinais de igual, o alfabeto se limita a letras, dígitos e dois símbolos, e decodificar produz texto legível ou um cabeçalho de arquivo reconhecível, em vez de ruído.

Vale reconhecer esses cabeçalhos também na forma codificada, porque eles identificam o conteúdo antes de você salvá-lo. Um payload decodificado que começa com os bytes 89 50 4E 47 é um PNG; FF D8 FF é um JPEG; 50 4B 03 04 é um zip, o que inclui todo documento do Office; 25 50 44 46 é um PDF. Em Base64, uma string que começa com iVBORw0KGgo é um PNG e /9j/ é um JPEG, e as duas aparecem o tempo todo em payloads de API e data URIs.

Quando a decodificação não produz nem texto nem um cabeçalho conhecido, as explicações usuais são que a string é Base64 seguro para URL sendo decodificado com o alfabeto padrão, que foi codificada duas vezes, ou que não é Base64 e sim hexadecimal ou base32. Cada uma se distingue em um segundo: strings seguras para URL contêm hífen ou sublinhado, as duplamente codificadas decodificam para outra string com cara de Base64, e hexadecimal usa apenas dezesseis caracteres.