Codificar e decodificar Base64

Como usar

1. Cole o texto ou o Base64 no painel Entrada, use o botão Colar, abra um arquivo de texto ou toque em Exemplo.
2. No modo Auto o sentido é detectado sozinho e o rodapé explica o motivo (por exemplo, “alfabeto válido, tamanho coerente e decodifica em texto UTF-8”). Escolha Codificar ou Decodificar para forçar o sentido.
3. Ao codificar, escolha o alfabeto (Padrão com + e / ou URL-safe com - e _), ligue ou desligue o padding (=) e quebre em linhas de 76 caracteres (MIME) ou 64 (PEM).
4. Se o Base64 tiver erro, a mensagem mostra a linha, a coluna e o que corrigir; clique em Ir para o erro para selecionar o caractere exato.
5. Copie ou baixe o resultado no rodapé do painel. Conteúdo binário (uma imagem PNG, um PDF) é baixado com a extensão certa, e Usar como entrada leva o resultado de volta para a Entrada.

Exemplos

Olá, mundo!

T2zDoSwgbXVuZG8h

<<???>>

PDw_Pz8-Pg

SGVsbG8@V29ybGQ=

Linha 1, coluna 8 — Caractere inválido “@”: Base64 só usa letras sem acento, números, + e / (ou - e _ no Base64URL).

Como o Base64 funciona

Base64 (RFC 4648) transforma bytes em texto usando só 64 símbolos seguros: A–Z, a–z, 0–9, + e /. A cada 3 bytes (24 bits) ele gera 4 símbolos de 6 bits. Por isso o resultado é sempre cerca de 33% maior que o original (4 símbolos para cada 3 bytes): “Olá, mundo!” tem 12 bytes em UTF-8 e vira 16 símbolos.

Quando o último grupo tem só 1 ou 2 bytes, faltam bits para fechar os 4 símbolos. O sinal = completa o grupo: um = quando sobram 2 bytes, == quando sobra 1. Ele não carrega dado nenhum, só marca onde o texto termina.

Base64 padrão, Base64URL, MIME e PEM

O + e o / do Base64 padrão têm significado em URLs e nomes de arquivo. O Base64URL troca os dois por - e _ e costuma dispensar o =. É o formato de JWT, OAuth (PKCE) e de identificadores que vão em links.

Alguns formatos quebram o Base64 em linhas: e-mail MIME (RFC 2045) usa 76 caracteres por linha e certificados e chaves PEM (RFC 7468) usam 64. Aqui a decodificação aceita os dois alfabetos e ignora as quebras de linha, mas acusa quando a mesma entrada mistura - ou _ com + ou /.

Acentos, emoji e UTF-8

Base64 codifica bytes, não letras. Antes, o texto precisa virar bytes, e o padrão da web é UTF-8: “é” ocupa 2 bytes, “☕” 3 e “👋” 4. As funções btoa e atob do navegador trabalham com Latin-1: btoa recusa emoji com InvalidCharacterError, e atob devolve “é” no lugar de “é” porque lê cada byte como uma letra.

Esta ferramenta converte texto em bytes UTF-8 e só então em Base64. Na volta, a decodificação é estrita: se os bytes não formam texto UTF-8 válido, ela mostra que o conteúdo é binário em vez de exibir caracteres trocados.

O mesmo “é” pode ser escrito de dois jeitos em Unicode: um caractere só (NFC) ou “e” seguido de um acento combinante (NFD, comum em nomes de arquivo do macOS). Na tela parecem iguais, mas os bytes são outros: o NFC vira w6k= e o NFD vira ZcyB. O texto não é normalizado, para o Base64 sair exatamente dos bytes que você colou.

Base64 não é criptografia

Qualquer pessoa decodifica Base64 sem chave nenhuma, em qualquer linguagem. Ele serve para transportar bytes por canais que só aceitam texto (JSON, cabeçalhos HTTP, e-mail, data: URIs), não para esconder nada. Um header Authorization: Basic, por exemplo, leva usuário e senha legíveis para quem tiver acesso a ele.

Para conferir se um conteúdo foi alterado, use um hash (SHA-256). Para manter algo em sigilo, use criptografia de verdade, como AES-GCM. Esta página roda inteira no seu navegador: o texto não é enviado para servidor nem salvo, nem no armazenamento local.

Perguntas frequentes

Base64 é criptografia? Dá para guardar senha em Base64?

Não. Base64 é só uma forma de escrever bytes como texto, e qualquer um desfaz com um comando. Senha guardada em Base64 está, na prática, em texto puro. Para senhas use um hash próprio para isso (Argon2, bcrypt ou scrypt); para sigilo, criptografia.

Por que o Base64 termina com = ou ==? Posso tirar?

O = completa o último grupo de 4 símbolos quando o tamanho original não é múltiplo de 3 bytes. Dá para tirar quando quem lê sabe completar sozinho, como no Base64URL dos JWT. Bibliotecas estritas recusam a falta (“incorrect padding”); esta ferramenta completa automaticamente e avisa.

Por que o Base64 fica uns 33% maior? E por que acento pesa mais?

Cada 3 bytes viram 4 símbolos, então o tamanho cresce 4/3. O que conta são bytes, não letras: em UTF-8 uma letra sem acento ocupa 1 byte, uma letra acentuada 2 e um emoji 4. Por isso um texto cheio de acentos e emoji gera um Base64 bem mais longo que o número de caracteres sugere.

Por que aparece “é” ou dá erro com acento e emoji?

Porque alguma etapa tratou o texto como Latin-1 em vez de UTF-8. No navegador, btoa recusa caracteres fora do Latin-1 e atob devolve cada byte como uma letra, e o “é” (2 bytes) vira “é”. A solução é converter texto em bytes UTF-8 antes de codificar e ler os bytes como UTF-8 ao decodificar, como esta página faz.

Como codificar e decodificar Base64 no terminal, em JavaScript e em Python?

Terminal: printf '%s' 'texto' | base64 para codificar e base64 -d para decodificar (echo sem -n acrescenta uma quebra de linha ao texto). Node.js: Buffer.from(t, "utf8").toString("base64") e Buffer.from(b, "base64").toString("utf8"); troque "base64" por "base64url" para o alfabeto de URL. Python: base64.b64encode(t.encode()).decode() e base64.b64decode(b).decode(); para URL, base64.urlsafe_b64encode.

O que significam “incorrect padding” e “invalid character”?

“Incorrect padding” quer dizer que o tamanho não fecha em grupos de 4: falta =, sobra = ou falta um caractere (comum em Base64URL copiado de um JWT). “Invalid character” aponta um símbolo fora do alfabeto, como espaço no meio, @, letra acentuada ou - e _ numa biblioteca que só aceita o padrão. Cole aqui e a mensagem mostra a linha, a coluna e o que corrigir.