Resumo rapido: base64 nao e criptografia. E apenas um esquema de codificacao para transportar binario em canal que aceita so texto. Qualquer pessoa decodifica em segundos. Nao use base64 para esconder senha ou token sensivel.
Conversor base64: codificacao binario-em-texto explicada
Base64 e uma das codificacoes mais antigas e mais mal entendidas da internet. Aparece em e-mail, token de autenticacao, imagem inline em CSS, chave PEM de certificado. Confundido direto com criptografia — nao e. Base64 apenas representa bytes arbitrarios usando 64 caracteres ASCII seguros pra trafegar em canal textual.
A razao historica e simples: SMTP foi projetado pra texto ASCII de 7 bits. Anexar binario direto corrompia o transporte. Base64 transforma os bytes em caracteres seguros ao custo de inflar o tamanho em ~33%.
Onde base64 aparece
JWT: tres pedacos separados por ponto, cada pedaco em base64URL. O payload central traz claims (user_id, exp, iat) decodificaveis em segundos — nao confunda com criptografia, e assinado, nao cifrado.
Data URI em CSS: background: url(data:image/png;base64,iVBORw0KGgo...). Vale a pena pra icone muito pequeno; pra imagem media, a requisicao HTTP separada e melhor (cache, paralelismo).
HTTP Basic Authentication: Authorization: Basic dXNlcjpzZW5oYQ==. Esse "dXNlcjpzZW5oYQ==" decodifica direto pra "user:senha". Por isso Basic Auth so faz sentido sobre HTTPS — sem TLS, a credencial trafega praticamente em claro.
Certificados PEM: o conteudo entre -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- e um blob X.509 (DER) codificado em base64.
Variantes do base64
| Variante | Caracteres extras | Padding | Onde se usa |
|---|---|---|---|
| Base64 padrao (RFC 4648) | + e / | Sim (=) | E-mail, MIME, PEM |
| Base64URL | - e _ | Opcional | JWT, URL params |
| Base64 MIME | + e / | Sim | Quebra em linhas de 76 caracteres |
Acentuacao e UTF-8
O btoa() nativo do JS quebra com qualquer caractere fora do ASCII (acento, emoji, kanji). btoa('configuração') lanca exception. O caminho correto e codificar pra bytes UTF-8 primeiro, depois aplicar base64 nos bytes.
A ferramenta faz isso via TextEncoder/TextDecoder, entao acento, emoji e caractere chines passam sem ajuste manual.
Base64 nao esconde nada
Senha em base64 continua exposta. O algoritmo e publico, reversivel em milissegundos. Pra confidencialidade real, use cifra simetrica autenticada (AES-256-GCM, ChaCha20-Poly1305). Pra senha de usuario em banco, hash lento com salt (bcrypt, scrypt, Argon2).
A matematica do base64
O alfabeto tem 64 simbolos: 26 maiusculas + 26 minusculas + 10 digitos + "+" + "/". 64 = 2^6, entao cada caractere carrega exatamente 6 bits. O nucleo da operacao: pegar blocos de 24 bits da entrada (3 bytes) e emitir 4 simbolos de 6 bits.
Quando a entrada nao fecha multiplo de 3 bytes, completa-se com bits zero e marca-se o resto com "=" (padding). Dai vem "==" no final (2 bytes faltando pro bloco) ou "=" sozinho (1 byte faltando). O padding permite reconstruir o tamanho original sem ambiguidade na decodificacao.
O overhead de ~33% sai direto da razao 4/3: 3 bytes de entrada produzem 4 bytes de saida. Com quebras de linha MIME (76 chars) e padding, o custo real fica entre 33% e 37%.
Casos de uso reais
- E-mail (MIME): PDF, foto, planilha viajam em base64 no corpo do e-mail. SMTP nasceu pra texto 7 bits.
- Data URIs:
data:image/png;base64,iVBORw0KGgo...embute a imagem inteira em CSS ou HTML, sem requisicao HTTP extra. Bom pra icone pequeno ou logo critico pro LCP. - JWT: header.payload.signature, cada parte em base64URL. Payload e legivel apos decodificar — assinado, nao cifrado.
- HTTP Basic Auth:
Authorization: Basic dXNlcjpzZW5oYQ==. Credencial em base64 plano; sem TLS, trafega praticamente em claro. - Certificados PEM: blob X.509 (DER) entre BEGIN/END CERTIFICATE codificado em base64.
- DNS TXT: DKIM, SPF longo, tokens de verificacao costumam carregar base64 dentro do TXT, ja que DNS exige texto imprimivel.
Quando NAO usar base64
Base64 nao da confidencialidade. Qualquer um decodifica em milissegundos com a ferramenta acima. Pra protecao real:
- TLS em transito (HTTPS, SMTPS, IMAPS).
- AES-256-GCM ou ChaCha20-Poly1305 pra cifra simetrica autenticada em repouso.
- libsodium ou age pra envelope com chave publica.
Base64 nesses contextos so empacota o ciphertext em texto seguro pro canal. A protecao vem da cifra; a codificacao e neutra.
Variante URL-safe (RFC 4648 secao 5)
O base64 padrao usa "+" e "/" como caracteres 62 e 63. Esses dois tem significado especial em URL ("+" vira espaco no decode de form, "/" separa segmentos de caminho). A RFC 4648 secao 5 define a variante base64URL:
- + vira - (hifen)
- / vira _ (underline)
- = de padding omitido (ou mantido, conforme implementacao)
JWT, OAuth state, query params, token de reset de senha — tudo usa base64URL. A ferramenta acima aceita as duas variantes na decodificacao automaticamente (converte "-" e "_" de volta antes de processar).
Codificando "saber meu IP"
"saber meu IP" tem 12 caracteres ASCII, 12 bytes em UTF-8. Em base64 padrao da c2FiZXIgbWV1IElQ — 16 caracteres de saida, o overhead esperado de 33%. Decodificar c2FiZXIgbWV1IElQ devolve "saber meu IP" bit a bit. Base64 e bijetivo.
Sobre como esses formatos sao especificados oficialmente, veja o que sao RFCs e padroes de internet. A definicao do base64 esta na RFC 4648. Chave DKIM e SPF longo em TXT de DNS frequentemente carregam base64 (o que e DNS).
Base64: Perguntas Frequentes
Base64 representa dados binários usando apenas 64 caracteres ASCII, útil para enviar conteúdo binário por canais que só aceitam texto.
Não. Base64 é apenas codificação reversível sem chave. Qualquer pessoa com o resultado pode decodificar e ler o conteúdo original.
Em emails MIME, imagens embutidas em HTML via data URI, tokens JWT, certificados PEM e payloads de API que carregam binário em JSON.
Sim. O conversor trata o texto em UTF-8 antes de codificar, garantindo que ç, ã, é e demais caracteres voltem corretos na decodificação.
Os caracteres = são preenchimento (padding) para deixar a saída em blocos de 4. Eles fazem parte do padrão e devem ser mantidos.
Base64URL substitui + e / por - e _, evitando conflito em URLs. JWT e tokens web costumam usar essa variante.