Codificar e Decodificar Base64

O que o Base64 faz

Base64 pega qualquer coisa que esteja no computador, um texto, uma foto, um PDF, um certificado, e reescreve tudo usando só 64 caracteres seguros: as 26 letras maiúsculas, as 26 minúsculas, os 10 algarismos, o sinal de mais e a barra.

Ele existe por um motivo antigo e ainda vivo. Vários canais da internet foram feitos para carregar texto simples, e não arquivo: o corpo de um e-mail, um campo de XML, um valor dentro de um JSON, um endereço de site. Quando um byte qualquer passa por esses canais, ele pode ser cortado, trocado ou interpretado como comando. O Base64 resolve isso convertendo tudo em caracteres que ninguém confunde com nada.

Não é compressão, não é criptografia e não é assinatura. É só uma forma diferente de escrever a mesma coisa, e ela é reversível em um clique.

Base64 não é criptografia, e essa é a parte que importa

Esse é o mal-entendido que mais dá problema. Como o resultado fica com cara de código embaralhado, muita gente usa Base64 para esconder senha em arquivo de configuração, em planilha ou dentro do próprio sistema, achando que está protegendo alguma coisa.

Não está. Base64 não tem senha, não tem chave e não tem segredo: qualquer pessoa que veja o texto volta ao conteúdo original em um clique, inclusive nesta página. É como escrever a senha de trás para frente e achar que ninguém vai perceber.

Faz o teste você mesmo. Monte um cabeçalho de autenticação ali no segundo formulário e depois cole o resultado no primeiro, no modo decodificar: usuário e senha voltam inteiros na tela.

Onde o Base64 aparece na vida de quem tem empresa

Você provavelmente já esbarrou nele sem saber o nome.

Integração com API. Sistema de nota fiscal, ERP, gateway de pagamento e transportadora costumam pedir um cabeçalho Authorization: Basic, que é o seu usuário e a sua senha grudados por dois pontos e codificados em Base64. É a autenticação mais simples que existe, e ela só é aceitável porque viaja dentro do HTTPS.

Nota fiscal eletrônica. O XML da NF-e e o retorno de vários webservices de NFS-e carregam pedaços em Base64: a assinatura digital, o certificado e, em algumas prefeituras, o PDF da nota devolvido dentro do próprio XML. Quando um sistema devolve um bloco enorme de letras sem sentido no lugar do arquivo, quase sempre é isso.

Certificado digital. O arquivo do certificado A1 vira Base64 quando é enviado para um sistema na nuvem. O formato PEM, aquele que começa com -----BEGIN CERTIFICATE-----, é exatamente Base64 quebrado a cada 64 caracteres.

Logo dentro do e-mail ou do site. Uma imagem pode ser embutida no próprio código como data:image/png;base64, seguida de um monte de caracteres. Isso é o data URI: a imagem vai junto com a página, sem precisar de arquivo separado. Cole um data URI aqui na ferramenta e ela diz que tipo de arquivo está lá dentro.

Anexo de e-mail. Todo anexo viaja em Base64. É por isso que um arquivo de 10 MB ocupa mais de 13 MB no caminho, e é por isso que o servidor do seu e-mail recusa anexo antes do limite que ele anuncia.

Por que o arquivo engorda um terço

A conta é fixa: a cada 3 bytes de conteúdo saem 4 caracteres de Base64. Isso dá 33% a mais, sempre, mais o arredondamento do final.

O motivo é que cada caractere do Base64 guarda 6 bits, e cada byte tem 8. Quatro caracteres de 6 bits somam 24 bits, que é exatamente o tamanho de 3 bytes. A conta fecha certinho, e o preço é o crescimento.

Na prática isso significa duas coisas para quem manda arquivo: o limite de anexo do provedor vale para o tamanho já codificado, e mandar imagem embutida em e-mail marketing pesa mais do que hospedar a imagem e apontar o endereço dela.

Acento e emoji: o erro que o navegador comete sozinho

Base64 trabalha com bytes, e não com letras. Então antes de codificar é preciso decidir como cada letra vira byte, e essa decisão é a codificação de caracteres.

A internet inteira usa UTF-8, em que letra sem acento ocupa 1 byte, letra com acento e o ç ocupam 2 e emoji ocupa 4. A função pronta que os navegadores trazem para Base64, o btoa, é anterior a isso e só entende Latin-1: com acento, ela quebra ou devolve letra trocada na volta.

É a causa clássica do texto que sai como “Ação” depois de dar a volta. Esta ferramenta trabalha em UTF-8 de verdade, então “Ação 🚀” volta exatamente igual, com o foguete e tudo.

Base64 padrão e Base64 de URL

O Base64 comum usa dois caracteres que atrapalham dentro de um endereço de site: o sinal de mais e a barra. A barra separa pastas, e o mais vira espaço em formulário. O sinal de igual do final também vira %3D quando passa por uma URL.

Por isso existe a variante URL-safe, que troca o mais por hífen, a barra por sublinhado e dispensa o igual. É essa a variante usada em token de sessão, em link de confirmação de e-mail e nas duas primeiras partes de um JWT.

Na decodificação aqui, a variante é reconhecida sozinha. Se o texto vier misturando as duas, a ferramenta avisa: isso não acontece em conteúdo íntegro, e é sinal de que alguma coisa trocou os caracteres no caminho.

O sinal de igual do final serve para quê

Como o Base64 trabalha de 3 em 3 bytes, quando o conteúdo não é múltiplo de 3 sobra pedaço. O sinal de igual é o enchimento que completa o bloco: um igual quando sobraram 2 bytes, dois iguais quando sobrou 1.

Ele não guarda informação nenhuma, e por isso muita gente corta o igual sem dó em endereço de site. A ferramenta aceita os dois jeitos e completa sozinha quando falta, mas vale saber que boa parte das bibliotecas de programação recusa o texto sem o enchimento.

Tem um detalhe que quase nenhum conversor mostra. Quando sobra pedaço, os bits que não viraram byte precisam ser zero. Existe Base64 que decodifica normalmente e mesmo assim está escrito errado, porque esses bits vieram diferentes de zero: QQ== e QR== devolvem os dois a letra A, mas só o primeiro está na forma correta. Quando isso acontece, a ferramenta avisa e mostra qual seria a forma certa, porque um sistema mais rigoroso vai recusar.

JWT: o token que qualquer um lê

Se você integra com alguma API moderna, vai esbarrar num token JWT: um texto comprido dividido em três pedaços por pontos. Cole um deles aqui e a ferramenta abre os dois primeiros pedaços, que são Base64 puro, e mostra até a data de validade do token.

Repare no que acabou de acontecer: o conteúdo abriu sem nenhuma senha. As duas primeiras partes de um JWT são legíveis por qualquer pessoa que tenha o token na mão. A terceira parte é a assinatura, e o papel dela é outro: ela não esconde nada, só prova que ninguém alterou o conteúdo pelo caminho.

A regra prática, então, é simples. Nunca coloque dentro de um JWT algo que não possa ser lido, e nunca cole um token de produção em site de conversão que você não conhece. Aqui a conversão acontece dentro do seu navegador e nada é enviado, mas isso não vale para toda ferramenta da internet.

Quando a ideia era esconder de verdade

Se o objetivo é proteger uma senha ou uma chave de API, Base64 não serve. O que serve, em ordem de facilidade:

Nunca escrever a chave dentro do código. Ela vai para uma variável de ambiente ou para um arquivo de configuração que não entra no repositório. Chave commitada é chave vazada, mesmo em repositório privado.

Gerenciador de senhas para a equipe. Chave de API compartilhada por WhatsApp ou por planilha do Drive circula para sempre. Um cofre de senhas resolve isso e ainda registra quem viu o quê.

Token com prazo em vez de senha eterna. Quando a API oferece, prefira o token que vence: se ele vazar, o estrago tem data para acabar.

HTTPS sempre. No cabeçalho Basic, o que protege é só o cadeado do endereço. Integração em http simples entrega usuário e senha para qualquer um no mesmo Wi-Fi.

Combina com

Para ver o que acontece um andar abaixo, no nível dos bits, o tradutor de código binário mostra a mesma ideia em zeros e uns e explica a conta do UTF-8. Se o que você precisa é gerar uma chave forte em vez de esconder uma fraca, o gerador de senha resolve. E se o Base64 apareceu num XML de nota, o validador de chave da NF-e ajuda a conferir o resto do documento.