Codificador e decodificador Base64 gratuito on-line

O que é Base64?

Base64 é um esquema de codificação binário-para-texto, uma forma de representar qualquer sequência de bytes (dados binários) como uma sequência de caracteres ASCII comuns que podem viajar por canais somente-texto sem corrupção. O nome reflete o tamanho do alfabeto: 64 caracteres escolhidos especificamente porque sobrevivem a uma transmissão limpa de 7 bits sem alteração. O alfabeto padrão é A-Z (posições 0-25), a-z (26-51), 0-9 (52-61), depois + (62) e / (63). O caractere = fica reservado como preenchimento quando o comprimento de entrada não é múltiplo exato de três. Cada três bytes de entrada (24 bits) viram quatro caracteres de saída (cada um carregando 6 bits), por isso os dados codificados em Base64 são cerca de 33 % maiores que o original.

A mecânica: tomar três bytes (24 bits), reagrupar em quatro fatias de 6 bits, buscar cada fatia no alfabeto de 64 caracteres. O exemplo clássico: os três bytes ASCII M a n (0x4D 0x61 0x6E) formam o padrão de 24 bits 01001101 01100001 01101110; reagrupado em fatias de 6 bits: 010011 010110 000101 101110 = 19, 22, 5, 46 em decimal = caracteres T W F u. Então "Man" codifica em Base64 como "TWFu". Se o comprimento de entrada não é divisível por três, o codificador preenche com um ou dois =: 1 byte de entrada produz 2 caracteres + ==, 2 bytes de entrada produzem 3 caracteres + =.

Uma breve história do Base64

Base64 nasceu do esforço Privacy Enhanced Mail (PEM) do IETF. RFC 989 em fevereiro de 1987 foi a primeira definição formal; RFC 1113 em agosto de 1989 a revisou; RFC 1421 em fevereiro de 1993 finalizou a especificação PEM com a codificação Base64 incluída. Base64 entra no e-mail mainstream quando a especificação MIME (Multipurpose Internet Mail Extensions) a adota: RFC 2045 em novembro de 1996 definiu Base64 como codificação padrão para anexos binários de e-mail, por isso cada PDF ou imagem que você anexou a um e-mail viajou pela rede como Base64. A especificação canônica atual é RFC 4648 («The Base16, Base32, and Base64 Data Encodings»), publicada em outubro de 2006 por Simon Josefsson, que substitui RFC 3548 (julho de 2003) e unifica as codificações da família Base16 / Base32 / Base64 num único documento. RFC 4648 é a spec a que toda implementação moderna de Base64 visa.

Base64 URL-safe, por que dois caracteres são trocados

O alfabeto padrão do Base64 usa + e /, dois caracteres reservados em URL. + em uma string de consulta URL tipicamente significa «espaço» (convenção form-encoded); / é o separador de caminho. Colocar Base64 padrão em uma URL implica percent-encoding de ambos, o que infla ainda mais a string e a deixa feia. RFC 4648 §5 define uma variante URL-safe: substituir + por - (hífen-menos) e / por _ (sublinhado). Às vezes chamada Base64URL ou base64url. O resultado é uma string que se encaixa diretamente em URLs sem escape adicional, exatamente o que JWT (JSON Web Tokens), parâmetros state do OAuth, IDs de credenciais WebAuthn e a maioria das APIs web modernas usam. Algumas implementações também descartam o = final de preenchimento porque o comprimento é implícito pelo próximo campo. A estrutura de três partes separadas por pontos do JWT (cabeçalho.carga.assinatura) consiste em três segmentos codificados em Base64URL; se você já decodificou um JWT à mão, viu os caracteres - e _ que o marcam como Base64URL em vez de Base64 padrão.

A família Base-N, Base16, Base32, Base58, Base85

Base64 não é a única codificação binário-para-texto. Base16 (hex) usa 16 caracteres (0-9 e A-F), 100 % de expansão (cada byte vira 2 caracteres hex), mas trivialmente legível e o padrão universal para saída de hash, somas de verificação e identificadores de máquina. Base32 (RFC 4648, variante de Crockford também) usa 32 caracteres com cuidado para excluir pares visualmente ambíguos como 0/O e 1/I/L; 60 % de expansão; usado em chaves secretas TOTP, ULIDs e endereços onion do Tor. Base58 é canônico para Bitcoin: 58 caracteres excluindo os facilmente confundidos 0/O/I/l, mais os especiais de Base64 padrão +/=. Endereços Bitcoin, endereços Solana e muitos identificadores de carteiras cripto usam Base58Check (Base58 mais uma soma de verificação de 4 bytes). Base85 / Ascii85 empacota mais densidade (codificando 4 bytes como 5 caracteres, apenas 25 % de expansão) mas usa um alfabeto que inclui pontuação URL-unsafe; os formatos PostScript e PDF da Adobe usam Base85 internamente para dados binários incorporados. O compromisso geral: mais caracteres no alfabeto significa menos expansão mas um conjunto de caracteres mais restrito; menos caracteres significa transporte mais seguro ao custo de saída maior.

Usos comuns para Base64

• Anexos de e-mail (MIME). RFC 2045 desde 1996. Cada PDF, imagem ou documento que você anexou a um e-mail viajou pela rede como Base64 porque SMTP era originalmente um protocolo de texto limpo de 7 bits que não conseguia lidar com binário cru.
• URI data: em HTML/CSS. data:image/png;base64,iVBORw0KGgo... incorpora uma imagem pequena diretamente no HTML ou em uma folha de estilo CSS, eliminando uma requisição HTTP. Útil para ícones abaixo de ~10 KB; contraproducente para imagens maiores porque a expansão Base64 de 33 % supera a economia do custo de requisição HTTP.
• Binário em payloads JSON. JSON é somente-texto por spec, não há jeito de colocar bytes crus em um valor JSON. APIs que precisam transmitir imagens, PDFs ou outro binário os incorporam como strings Base64 em um campo JSON. Os payloads de webhooks do Stripe, as APIs MMS do Twilio e muitos endpoints de AI-vision usam esse padrão.
• JWT (JSON Web Tokens). As três partes separadas por pontos de um JWT (cabeçalho.carga.assinatura) são todas codificadas em Base64URL. A spec do JWT (RFC 7519, maio de 2015) se apoia em JOSE (RFC 7515-7518, também maio de 2015), todas mandando Base64URL em todos os lugares.
• OAuth e OpenID Connect. O parâmetro state, os code verifiers PKCE, os ID tokens e os access tokens em muitas implementações usam Base64URL.
• Autenticação HTTP Basic. O cabeçalho Authorization: Basic dXNlcjpwYXNz carrega Base64(usuário:senha). Observação: isso é codificação para transporte, NÃO criptografia, Basic Auth sobre HTTP puro expõe credenciais em texto claro a qualquer um observando a rede. Combine sempre com HTTPS.
• Subresource Integrity (SRI). O atributo integrity="sha384-..." em tags <script> e <link> carrega um hash codificado em Base64 do conteúdo esperado do arquivo; navegadores verificam que o arquivo baixado corresponde antes de executar.
• Fundos SVG em CSS. background-image: url("data:image/svg+xml;base64,...") incorpora um SVG diretamente em uma folha de estilo. A forma Base64 às vezes é preferida à forma URL-encoded (que mantém o SVG legível mas usa regras de escape diferentes).

Codificar não é criptografar, um erro comum de segurança

Base64 oferece zero segurança. A codificação é totalmente reversível por qualquer um em milissegundos, o alfabeto é público, o algoritmo é trivial, e qualquer navegador ou comando CLI de uma linha pode decodificá-lo. Apesar disso, «dados sensíveis codificados em Base64» é um dos exemplos mais citados em CWE-261 do MITRE (Weak Encoding for Password) e aparece constantemente em auditorias de segurança: chaves de API «ofuscadas» com Base64 em código cliente; senhas «codificadas» com Base64 em backups de bancos de dados; segredos «criptografados» com Base64 antes de serem committados em um repositório Git público. Nenhum deles está protegido. Se você precisa de confidencialidade real, use criptografia real: AES-256-GCM para simétrica, RSA-OAEP ou ECDH+ChaCha20-Poly1305 para assimétrica. Base64 é apropriado para transporte (transformar binário em forma text-friendly) mas nunca para proteção.

Implementação no navegador: btoa / atob e a armadilha Unicode

JavaScript expõe duas funções globais integradas para Base64: btoa() (binary-to-ASCII, codificar) e atob() (ASCII-to-binary, decodificar). Ambas são APIs legadas da era Netscape inicial e têm uma limitação famosa: só funcionam em strings de bytes Latin-1. Chamar btoa('é') lança InvalidCharacterError porque a string JavaScript 'é' contém um code point acima de U+00FF que não cabe em um único byte. A correção moderna é codificar primeiro para bytes UTF-8 via TextEncoder, depois converter o Uint8Array resultante para uma string Latin-1 para consumo de btoa(). O padrão: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Decodificação ao contrário: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Navegadores mais novos expõem Uint8Array.toBase64() e Uint8Array.fromBase64() como métodos integrados, mas a adoção ainda está se desenrolando em 2026, o polyfill via btoa/atob continua o default cross-browser. Para arquivos especificamente, FileReader.readAsDataURL() é o caminho mais simples: solte um arquivo em um input, o reader devolve uma string data:mime/type;base64,... com tudo corretamente codificado; remova o prefixo data: para obter só a porção Base64.

Escopo honesto: o que esta ferramenta faz e não faz

Esta ferramenta codifica texto ou arquivos (até 5 MB) para Base64 e decodifica strings Base64 para texto ou arquivos baixáveis. Usa o alfabeto padrão RFC 4648 (com + e /) por padrão; Base64URL URL-safe (com - e _) é um toggle de funcionalidade futura. Texto UTF-8 é manuseado corretamente via TextEncoder, a armadilha btoa-Latin-1 está corrigida. O limite de 5 MB existe porque Base64 expande os dados em 33 % e a string codificada vive inteira na memória do navegador; um arquivo binário de 5 MB produz ~6,7 MB de texto Base64 mais o buffer original, o que funciona em qualquer dispositivo moderno. Para arquivos maiores, as alternativas padrão são linha de comando base64 em macOS/Linux (base64 -i input.bin -o output.txt), o módulo base64 do Python, ou Buffer.from(data).toString('base64') do Node.js. Esta ferramenta não manuseia: Base64 em streaming (codificação arquivo-por-pedaço para arquivos maiores que a memória); a variante URL-safe nesta versão (planejado); nem codificação quoted-printable MIME (um esquema RFC 2045 diferente para conteúdo texto de e-mail).

Privacidade: por que só-navegador importa

Base64 não é criptografia, mas os dados que se codificam são frequentemente sensíveis: chaves de API que você está incorporando em um arquivo de config, certificados que você está codificando para transporte, capturas internas que você está incorporando como URI data em documentação, ou recibos PDF que você está codificando para um cliente. Codificadores do lado servidor veem sua entrada. Esta ferramenta roda inteira no seu navegador via JavaScript, verifique na aba Network do DevTools ao clicar Encode, ou coloque a página offline (modo avião) após carregada e a ferramenta ainda funciona. Segura para codificar credenciais de API, capturas com PII, documentos internos ou qualquer dado que você não queira ver copiado no disco rígido de um desconhecido.

Perguntas frequentes

Base64 é seguro?

Não. Base64 é codificação, não criptografia. Qualquer pessoa pode decodificar uma string Base64. Nunca use Base64 para proteger dados sensíveis, use criptografia adequada (AES, RSA) para segurança.

Por que Base64 torna os arquivos maiores?

A codificação Base64 aumenta o tamanho dos dados em aproximadamente 33%. Três bytes de dados binários se tornam quatro caracteres Base64. Essa sobrecarga é o custo de poder transmitir dados binários como texto.

Posso codificar arquivos?

Sim! Arraste e solte qualquer arquivo no codificador, ou clique para procurar. O arquivo será convertido em uma URI de dados Base64 que você pode colar diretamente em HTML, CSS ou JavaScript.

Qual é a diferença entre Base64 e Base64URL?

Dois caracteres. Base64 padrão (RFC 4648 §4) usa + e / como caracteres 62 e 63 do alfabeto. Base64URL URL-safe (RFC 4648 §5) usa - e _ em vez deles, então a string codificada se encaixa diretamente em URLs sem percent-encoding. JWT, OAuth, WebAuthn e a maioria das APIs web modernas usam Base64URL. Esta ferramenta atualmente emite Base64 padrão; URL-safe está na lista de funcionalidades futuras. Para converter padrão para URL-safe à mão: substituir + por -, / por _, opcionalmente remover o = final de preenchimento.

Por que meu texto Unicode falha em algumas ferramentas Base64?

Porque a função legada btoa() do JavaScript só funciona em strings de bytes Latin-1, chamar btoa('é') lança InvalidCharacterError. Muitos codificadores antigos baseados em navegador usam btoa diretamente sem o passo de conversão UTF-8, então qualquer entrada não-ASCII quebra. Código moderno (e esta ferramenta) codifica strings via TextEncoder primeiro, produzindo uma sequência de bytes UTF-8 que btoa pode então codificar com segurança. O método integrado mais novo Uint8Array.toBase64() lida com UTF-8 nativamente mas ainda não é baseline em todos os navegadores.

Meus dados são enviados a algum lugar?

Não. Codificação e decodificação rodam inteiras no seu navegador via JavaScript. Texto e arquivos nunca atravessam a rede, verifique na aba Network do DevTools ao clicar Encode, ou coloque a página offline (modo avião) após carregada e a ferramenta ainda funciona. Segura para credenciais de API, capturas com PII, arquivos de config internos ou qualquer dado que você não queira ver copiado no disco rígido de um desconhecido.

Ferramentas relacionadas