Codificar em Base64

Base64 não criptografa nem comprime: ele reescreve bytes usando só 64 caracteres que sobrevivem a praticamente qualquer transporte. Pega três bytes, olha para eles como 24 bits e reparte em quatro pedaços de seis, e cada pedaço vira um caractere da tabela.

Daí vem o custo: o resultado ocupa um terço a mais do que o original, sempre. É o preço de conseguir atravessar um canal que só entende texto, e é a razão pela qual um anexo de e-mail pesa mais do que o arquivo que está dentro dele — o e-mail continua sendo um protocolo de texto por dentro.

O alfabeto padrão usa `+` e `/` nos dois últimos caracteres. Os dois têm significado dentro de uma URL: a barra separa segmentos de caminho e o sinal de mais é lido como espaço num query string. Um valor em Base64 padrão colocado num endereço chega, portanto, alterado.

A variante segura para URL troca esses dois por `-` e `_`, que não significam nada em nenhuma parte de um endereço. É o que os JWT usam, e é por isso que um token copiado de um cabeçalho não tem barra nem sinal de mais. Se o valor vai viajar numa URL, essa é a opção; se não vai, o padrão é o que todo o resto espera.

O Base64 trabalha de três em três bytes. Quando a entrada não é múltiplo de três, sobra um ou sobram dois, e o padding é marcado com um ou dois sinais de igual no fim. Por isso um resultado termina em `=`, em `==` ou em nada, e por isso o comprimento dele é sempre múltiplo de quatro.

Esse padding é opcional em algumas especificações e obrigatório em outras, o que gera um desencontro recorrente: os JWT omitem de propósito, enquanto muitas bibliotecas se recusam a decodificar sem ele. Se alguma coisa está rejeitando um valor que parece correto, a contagem de caracteres é o primeiro lugar para olhar.

O Base64 codifica bytes, não caracteres, então antes é preciso decidir como o texto vira bytes. Aqui é sempre UTF-8, onde um `ç` são dois bytes e um `ã` também, e um emoji são quatro. A string em Base64 fica proporcionalmente mais longa do que ficaria se o texto fosse só ASCII.

É aí que mora o erro mais comum ao comparar com outra ferramenta: se o outro lado usou Latin-1, o `ç` foi um byte em vez de dois e o resultado não bate. Não é erro de nenhum dos dois codificadores — é que eles estavam codificando textos diferentes, e o desencontro está uma camada abaixo.

O cabeçalho `Authorization: Basic` é exatamente `usuário:senha` em Base64, e nada mais. Qualquer pessoa que veja o cabeçalho desfaz isso em um segundo, porque não existe chave nenhuma: é uma codificação, não uma criptografia.

O que protege essas credenciais é o HTTPS, e só ele. Por isso Basic Auth sobre HTTP puro equivale a mandar a senha em texto aberto, e por isso um cabeçalho desses numa captura de tela, num chamado ou num log é uma credencial exposta. Parecer ilegível não muda nada.

Uma imagem em Base64 dentro de um `src` economiza uma requisição, e isso é razoável para um ícone pequeno ou um SVG de poucos kilobytes. Daí para cima deixa de compensar: o arquivo cresce um terço, fica embutido no HTML e portanto não é cacheado separadamente, e o navegador precisa processar tudo antes de desenhar qualquer coisa.

O ponto em que o sinal vira depende da página, mas a regra de bolso se sustenta: abaixo de alguns kilobytes a data URI quase sempre ganha; acima de algumas dezenas ela quase sempre perde. Uma imagem grande embutida transforma cada visita num download completo do HTML inflado.

Aparece com certa frequência como jeito de «esconder» uma chave no código de um aplicativo, num arquivo de configuração ou num script. Não esconde nada: a volta é um botão, e as ferramentas que caçam segredos vazados reconhecem strings em Base64 justamente porque o padrão é fácil demais de detectar.

O que isso faz, sim, é tirar o alerta de quem passa o olho, e esse é o problema: um segredo em texto aberto se vê e se corrige, um em Base64 passa por uma revisão de código. Se alguma coisa precisa ficar oculta, é preciso criptografia com uma chave que more em outro lugar, ou simplesmente não colocar aquilo ali.

O e-mail quebra o Base64 em linhas de 76 caracteres porque um padrão de 1996 exige, e os certificados em formato PEM usam 64. Esse formato é perfeitamente válido, mas muitos decodificadores modernos engasgam com as quebras de linha se elas não forem removidas antes.

Esta página gera uma linha única e contínua, que é o que praticamente qualquer API atual espera. Se você precisa colar o resultado em algo que exige o formato quebrado, o corte fica por sua conta — e, se estiver decodificando algo com quebras, o decodificador deste site ignora as quebras.

Qualquer texto vira Base64: não existe entrada inválida e, portanto, não existe erro possível neste sentido. Isso é confortável e esconde uma armadilha, porque uma string em Base64 pode conter lixo e continuar com uma aparência impecável.

A verificação, se for necessária, vem antes: se você está codificando JSON, valide primeiro; se está codificando um identificador, confira se é o certo. Um valor malformado codificado fica exatamente igual a um bom, e o erro aparece do outro lado, onde custa muito mais para ser encontrado.

O que se cola aqui costuma ser justamente o que não convém mover: credenciais, um payload com dados de clientes, o conteúdo de um arquivo de configuração. Como a codificação acontece na página, não há compartilhamento conosco e portanto não somos operador desse conteúdo.

Isso se confere no painel de rede: enquanto você usa a ferramenta, nenhuma requisição sai levando a sua entrada. O que fica registrado está na página de privacidade — a visita e as requisições de publicidade e estatística. O conteúdo do campo não está entre elas, e com esse tipo de valor isso é a única coisa que importa.

Decodificar tem página própria, e a separação não é por comodidade. Quem codifica está construindo alguma coisa e tem uma decisão a tomar: qual alfabeto. Quem decodifica está lendo algo que chegou e tem um problema diferente: o que fazer quando o que sai não é texto.

As duas páginas compartilham o mesmo motor e explicam coisas diferentes porque as falhas são diferentes. Juntar as duas obrigaria cada visitante a atravessar a metade que não serve para ele, e deixaria de fora justamente os detalhes que o trouxeram até aqui.