Codificador e decodificador de Base64

O que o Base64 faz de verdade

O Base64 reescreve bytes arbitrários usando apenas 64 caracteres que sobrevivem à passagem por sistemas que esperam texto. Ele pega três bytes — 24 bits — e os divide em quatro grupos de seis bits. Seis bits guardam um número de 0 a 63, e cada número corresponde a um caractere. Entram três bytes, saem quatro caracteres, sempre.

Essa proporção é toda a história do custo: a saída em Base64 é um terço maior que a entrada, antes de qualquer quebra de linha. Quando o comprimento da entrada não é múltiplo de três, o codificador preenche o último grupo e o marca com sinais =: um quando sobram dois bytes, dois quando sobra um byte. É por isso que tantas strings Base64 terminam em = ou ==, e por isso nenhuma jamais termina em três.

Dois alfabetos, e o bug que nasce de misturá-los

O alfabeto padrão do RFC 4648 é A–Z, a–z, 0–9, mais + e /. Esses dois últimos são hostis dentro de uma URL: + é lido como espaço em dados codificados de formulário, e / encerra um segmento do caminho. Por isso o mesmo RFC define um segundo alfabeto, o base64url, que os substitui por - e _ e normalmente descarta o preenchimento, já que = também precisa de escape.

Os JSON Web Tokens usam base64url. A maioria dos cookies assinados e muitos identificadores de API também. Se um token decodifica como lixo em uma biblioteca e funciona em outra, o alfabeto é a primeira coisa a verificar: os dois não são intercambiáveis, embora pareçam quase idênticos. O decodificador desta página aceita os dois e os normaliza, o que é conveniente mas também significa que ele vai ler sem reclamar uma entrada que uma biblioteca rigorosa recusaria.

Por que o btoa() quebra na palavra "café"

O btoa() embutido no navegador não recebe texto. Ele recebe uma string binária, ou seja, cada caractere precisa caber em um byte. Qualquer coisa acima de U+00FF lança InvalidCharacterError, e é por isso que caracteres acentuados e emoji falham enquanto o inglês simples não falha — um bug que sobrevive aos testes e depois aparece em produção na primeira vez que alguém digita o próprio nome.

A correção é converter o texto para bytes UTF-8 antes e entregar esses bytes ao btoa(). Esta ferramenta faz isso com TextEncoder, então a saída dela bate exatamente com base64.b64encode(s.encode("utf-8")) do Python e com Buffer.from(s, "utf8").toString("base64") do Node. Isso também significa que a contagem de bytes nas estatísticas acima não é a contagem de caracteres: um caractere latino acentuado são dois bytes, e a maioria dos emoji são quatro.

Base64 não é criptografia

Não tem chave nem segredo. Qualquer pessoa que veja a string pode revertê-la em um segundo, usando esta mesma página. Uma senha guardada em Base64 em um arquivo de configuração é uma senha em texto puro fantasiada. O mesmo vale para o conteúdo de um JWT: ele é assinado, não escondido, e quem tiver o token consegue ler cada claim lá dentro.

Também não é compressão. Codificar um zip em Base64 deixa o arquivo maior, não menor.

Onde esta ferramenta para

• Texto entra, texto sai. Não há seletor de arquivos. Colar um arquivo binário em uma caixa de texto o destrói, então codificar uma imagem ou um PDF é outro trabalho, com outro formato.
• Uma passada só, na memória. Alguns megabytes funcionam bem. Dezenas de megabytes vão travar a aba, porque o codificador monta uma string intermediária tão longa quanto a entrada antes de começar.
• O decodificador é tolerante. Ele remove os espaços em branco, repõe o preenchimento que falta e aceita qualquer um dos dois alfabetos. Se uma string decodifica aqui mas falha no seu código, desconfie do preenchimento ou do alfabeto antes de desconfiar do seu código.
• Ele não sabe dizer o que os bytes significam. Se o resultado decodificado parece ruído, o conteúdo era binário. A ferramenta avisa, mas não vai identificar o tipo do arquivo para você.

A questão da quebra de linha

O MIME, o padrão por trás dos anexos de e-mail, limita as linhas a 76 caracteres. O PEM, o formato que guarda certificados e chaves privadas, quebra em 64. Os dois existem porque os servidores de e-mail antigos estragavam linhas longas. Os decodificadores deveriam ignorar as quebras de linha, e quase todos ignoram — mas alguns parsers rigorosos, principalmente em sistemas embarcados e corporativos antigos, não. Se um bloco Base64 copiado de um e-mail falha ao decodificar em algum lugar, as quebras de linha rígidas são as culpadas de sempre.

Perguntas frequentes

Por que meu texto acentuado quebra no btoa() mas funciona aqui?

O btoa() só aceita caracteres abaixo de U+0100, então qualquer coisa com acento ou emoji lança InvalidCharacterError. Esta ferramenta converte seu texto para bytes UTF-8 antes e codifica esses bytes, que é o que Python e Node fazem por padrão.

Qual é a diferença entre Base64 e base64url?

Os dois últimos caracteres do alfabeto. O Base64 padrão usa + e /, o base64url usa - e _, e o base64url normalmente não tem preenchimento =. JWTs e a maioria dos tokens embutidos em URLs usam base64url. O resto da codificação é idêntico.

Base64 é seguro?

Não. É uma codificação, não criptografia: não há chave e qualquer pessoa reverte na hora. Use para mover bytes por canais que só aceitam texto, nunca para esconder alguma coisa.

Por que minha string Base64 termina com sinais =?

Porque o comprimento da entrada não era múltiplo de três. Um = no final significa que o último grupo tinha dois bytes; dois = significam que tinha um. Uma string nunca termina com três caracteres de preenchimento.

Dá para decodificar uma string sem o preenchimento?

Dá. O decodificador desta página repõe o preenchimento antes de decodificar. Muitas bibliotecas rigorosas não fazem isso, e essa é a causa mais comum de um token base64url falhar em outro lugar e funcionar aqui.

Última atualização 19 de setembro de 2026