Por que uma string em Base64 é sempre cerca de 33% maior que o dado original?

Porque a codificação processa 3 bytes (24 bits) de entrada por vez, dividindo-os em 4 grupos de 6 bits, cada grupo virando um caractere Base64. Três bytes originais sempre produzem quatro caracteres codificados — uma expansão fixa de 4/3, aproximadamente 33%.

Por que btoa() sozinho falha ao codificar texto com acentuação?

Porque btoa() espera uma string onde cada caractere representa exatamente um byte (0-255), mas JavaScript armazena strings em UTF-16 internamente, e caracteres acentuados ou fora do ASCII básico não cabem nesse intervalo diretamente. A solução é converter via encodeURIComponent() e unescape() antes de chamar btoa(), um padrão documentado pela própria MDN.

Codificar uma senha em Base64 antes de armazená-la oferece alguma proteção?

Nenhuma. Base64 é reversível sem chave — qualquer pessoa com acesso ao valor codificado pode decodificá-lo instantaneamente, com esta mesma ferramenta ou qualquer outra. Não deve ser usado como substituto de hashing (para senhas) ou criptografia real (para dados confidenciais).

Base64 Codificador/Decodificador

Documentação técnica

Base64: por que 3 bytes viram 4 caracteres, e a armadilha do UTF-8

Base64 existe para representar dados binários arbitrários usando apenas caracteres seguros para transporte em texto (e-mail, URLs, JSON, XML) — 64 símbolos imprimíveis (A-Z, a-z, 0-9, +, /), cada um representando exatamente 6 bits de informação. A conversão trabalha em blocos de 3 bytes (24 bits) de entrada, que se dividem perfeitamente em 4 grupos de 6 bits — daí a proporção característica de Base64: toda entrada cresce em aproximadamente 33% de tamanho, porque 3 bytes originais (24 bits) viram 4 caracteres codificados. Quando a entrada não é múltiplo exato de 3 bytes, o caractere = no final preenche (pad) o último bloco incompleto — 1 ou 2 sinais de igual, dependendo de sobrar 1 ou 2 bytes no resto da divisão por 3.

Por que codificar texto com acento quebra com btoa() puro

A função nativa btoa() do navegador espera uma string onde cada caractere representa exatamente um byte (0-255) — o que funciona para ASCII puro, mas quebra com qualquer caractere fora desse intervalo (acentos, emojis, caracteres de outros alfabetos), porque JavaScript representa strings internamente em UTF-16, não byte a byte. A solução clássica — usada por este codificador — é converter o texto para sua representação percent-encoded via encodeURIComponent() e depois reverter esse escaping para bytes brutos via unescape() antes de passar para btoa(); a decodificação reverte os mesmos dois passos na ordem inversa. É um padrão de contorno amplamente usado, não uma peculiaridade desta ferramenta — a própria MDN documenta essa técnica como forma correta de lidar com Unicode em Base64 no navegador.

Base64 não é criptografia — é só uma representação

Um erro conceitual comum: tratar Base64 como se oferecesse alguma proteção de conteúdo. Não oferece nenhuma — é uma codificação reversível sem chave, decodificável por qualquer ferramenta (incluindo esta) instantaneamente. Seu uso legítimo é exclusivamente de transporte: embutir uma imagem pequena diretamente num HTML/CSS via data URI, transmitir dados binários dentro de um payload JSON (que só aceita texto), ou anexar um arquivo em um corpo de e-mail MIME. Para qualquer necessidade de confidencialidade real, a ferramenta correta é a Criptografia AES deste site, não Base64.