QuickUse Generator

Codificador/Decodificador Base64

Codifique ou decodifique Base64 no seu navegador. Suporte UTF-8, alternar padding, detecção automática URL-safe na decodificação. 100% client-side.

Modo
Padding
0 / 10000 caracteres
Saída Base64
A saída Base64 aparece aqui conforme você digita.

Guia editorial

Sobre este gerador

Leitura técnica honesta sobre o que está acontecendo por trás do botão Gerar.

Base64 é a fita-crepe da internet — o jeito universal de transportar dados binários por canais que só aceitam texto. Anexos de email desde início dos anos 90, tokens JWT, data URIs em CSS, headers HTTP Basic Auth, certificados em formato PEM. Sempre que um sistema que lida com bytes encontra um protocolo que só aceita caracteres imprimíveis, Base64 é a camada entre os dois.

O que o Base64 faz, no concreto

O Base64 pega um fluxo de bytes arbitrários e re-codifica usando um alfabeto de 64 caracteres que sobrevive a transporte por sistemas ASCII-only. Três bytes de entrada (24 bits) viram quatro caracteres de saída (4 × 6 bits = 24 bits). Quando o comprimento da entrada não é múltiplo de três, o codificador completa com um ou dois caracteres =, e a saída fica sempre múltiplo de quatro. O custo é fixo: a saída fica cerca de 33% maior que os bytes originais.

Isto não é criptografia, não é compressão, e não é hash. Qualquer pessoa que veja a string Base64 consegue reverter. Trate como encoding de transporte, nunca como medida de segurança. O número de bugs de produção do tipo "fiz Base64 da senha e está seguro" é genuinamente assustador.

Um pouco de história

O encoding é mais velho que a web moderna. As RFCs 989 (1987) e 1421 (1993) definiram o Privacy-Enhanced Mail (PEM), que usava um subconjunto ASCII de 64 caracteres para embutir mensagens RSA-assinadas e certificados em corpos de email. A RFC 1521 (1993, MIME) generalizou o encoding para qualquer anexo — daí vem a convenção de quebrar linha a cada 76 caracteres. Hoje a referência canônica é a RFC 4648 (2006), que unificou a família: §4 cobre o Base64 padrão, §5 cobre a variante URL-safe (Base64URL), e §6–§9 cobrem Base32 e Base16/hex.

Padding: manter ou tirar

Os = no final servem a um único propósito: avisar o decodificador quantos bytes a entrada original tinha quando a contagem não era múltipla de três. APIs modernas cada vez mais tiram o padding porque o tamanho já é implícito, e o = é chato em URLs (tem significado próprio em query string) e em JSON (sem semântica, mas é ruído).

O toggle desta ferramenta existe porque as duas convenções estão vivas em produção. A RFC 7519 (JSON Web Tokens) e a RFC 8037 (OKP JWKs) exigem Base64URL sem padding. A RFC 4648 §4 mantém o padding por padrão. Para codificar algo que vai numa query string de URL, use sem padding. Para codificar algo que vai num header HTTP Authorization: Basic (RFC 7617), mantenha o padding.

Padrão vs URL-safe — mesmos bytes, alfabetos diferentes

O Base64 padrão usa A-Z a-z 0-9 + /. Os caracteres + e / não são seguros em URLs: + é interpretado como espaço quando um servidor faz percent-decoding da query string, e / é o separador de caminho. Por isso a RFC 4648 §5 define a variante URL-safe: - substitui + e _ substitui /. Os bytes subjacentes são idênticos — só o alfabeto muda.

O decodificador desta ferramenta detecta automaticamente qual alfabeto você colou. Se vê um - ou _, trata como URL-safe e converte de volta para +// antes do atob. Se vê + ou /, trata como padrão. Se não vê nenhum dos dois (só letras e dígitos), assume padrão — os dois alfabetos concordam em [A-Za-z0-9].

Onde você vai encontrar Base64 na vida real

  • HTTP Basic Auth (RFC 7617): o header Authorization é Basic ${base64(usuario:senha)}. APIs de fintechs e bancos brasileiros (Itaú, Bradesco, Nubank, Inter, BTG) usam o esquema em pelo menos uma das superfícies — frequentemente combinando com mTLS no Open Finance. O Base64 aqui é transporte, não segredo: quem ver o header decodifica. Sempre HTTPS.
  • JSON Web Tokens (RFC 7519): três segmentos Base64URL separados por ponto. Os dois primeiros (header + payload) são JSON e podem ser decodificados sem chave — útil em debugging de autenticação de fintech BR onde o JWT carrega o ID do cliente e o escopo da sessão. Só a assinatura precisa do segredo.
  • Data URIs (RFC 2397): data:image/png;base64,iVBORw0KGgoAAA… embute um arquivo direto no HTML ou CSS. Comum em emails marketing brasileiros (logos pequenos) e em design system de sites BR. Útil para ícones, péssimo para imagens grandes — o overhead de 33% derrota a compressão HTTP.
  • Certificados PEM (RFC 7468): os blocos -----BEGIN CERTIFICATE----- que aparecem em config TLS são bytes DER embrulhados em Base64 com quebras de linha a cada 64 chars.
  • Anexos de email (MIME, RFC 2045 §6.8): todo anexo desde os anos 90 viaja como bytes codificados em Base64, com quebras a cada 76 caracteres.

Onde aparece com força no contexto brasileiro

Além dos casos de uso globais, há padrões que pesam mais aqui. Na NF-e (Nota Fiscal Eletrônica), o XML é assinado digitalmente e frequentemente trocado em envelopes Base64 entre ERPs e a SEFAZ — o cdec de retorno e os anexos PDF da DANFE quando enviados por API também viajam codificados. No Open Finance brasileiro (Bacen, regulado pela Resolução BCB nº 32/2020 e por instruções complementares), as estruturas JWS de consentimento e os payloads de pagamento iniciado usam Base64URL nas três partes do token e nos exemplos da documentação técnica da especificação Open Finance Brasil. Em integrações com gateways de boleto e PIX, é comum ver o QR Code dinâmico transportado como Base64 dentro da resposta JSON quando o cliente não quer baixar o PNG separado. Para um dev BR, "Base64" no log raramente é um caso de uso de email — é quase sempre payload de API regulada.

Vale notar uma assimetria útil: na maioria das integrações financeiras BR, o Base64URL (sem padding) é o esperado nos tokens (JWS/JWE), e o Base64 padrão (com padding) é o esperado em anexos binários (PDF, imagem, XML). Quando o decoder reclama de input inválido, o primeiro check é geralmente "padding errado para o canal".

UTF-8 e a armadilha do btoa

A função btoa() nativa do navegador só aceita caracteres no intervalo de byte 0–255. Chamar btoa('São Paulo') ou btoa('日本語') dispara InvalidCharacterError. O caminho correto é TextEncoder → bytes → string binária → btoa, que é o que esta ferramenta faz internamente. Se você vê "InvalidCharacterError" codificando Base64 em JavaScript, está chamando btoa direto numa string multi-byte. O fix é uma linha: codifique pra UTF-8 antes.

Privacidade: nada sai do seu navegador

Geradores de Base64 server-side vazam a entrada digitada via logs de load balancer, mirrors de requisição, logs de aplicação e qualquer middleware de analytics que capture corpos de POST. Isso pesa quando a entrada é uma senha (Basic Auth), um payload JWT, um certificado em rascunho ou um data URI de screenshot sensível. Esta ferramenta roda o pipeline inteiro localmente — o btoa e o atob da plataforma web estão em todo navegador moderno e dispensam requisição. O dropdown de entradas recentes também preserva privacidade: guarda a entrada e o modo escolhido (codificar-com-padding, codificar-sem-padding, decodificar), e recalcula a saída quando você restaura a entrada. A saída em si nunca toca disco — coerente com o que a LGPD (art. 12) espera quando o dado é potencialmente reversível.

Perguntas frequentes

Base64 é uma forma de criptografia?

Não. Base64 é um encoding — totalmente reversível por quem ler a saída. Existe para transportar dados binários por canais que só aceitam texto (email, URLs, headers HTTP, JSON). Se você precisa de confidencialidade de verdade, use TLS para transporte e cifra real (AES, ChaCha20) para dados em repouso. "Fiz Base64 da senha" é bug comum de produção, não controle de segurança.

Por que minha saída às vezes tem um ou dois = no final?

Padding. O Base64 emite quatro caracteres para cada três bytes de entrada. Quando a entrada não é múltipla de três, o codificador completa com um ou dois `=` para que a saída sempre seja múltipla de quatro. O Base64 sem padding (RFC 4648 §5 e a spec JWT) tira porque o tamanho já é implícito. Esta ferramenta deixa você alternar no modo Codificar; o decodificador aceita os dois.

Qual a diferença entre Base64 e Base64URL?

Mesmo encoding, alfabeto diferente. O Base64 padrão usa `+` e `/` para os caracteres 62 e 63. O Base64URL (RFC 4648 §5) troca por `-` e `_` para o resultado ficar seguro em URLs e nomes de arquivo. O payload em bytes é idêntico. O decodificador desta ferramenta detecta automaticamente qual alfabeto você colou e traduz internamente.

Dá para decodificar no terminal?

Dá. No macOS e Linux: `echo -n "SGVsbG8=" | base64 -d`. No Windows PowerShell: `[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("SGVsbG8="))`. Ambos esperam alfabeto padrão com padding — para Base64URL pode ser necessário trocar `-`/`_` de volta para `+`/`/` e adicionar `=` antes, ou usar uma flag tipo `base64 -d --decode` com adicional do sistema.

Por que o btoa() do JavaScript dispara erro em entrada não-ASCII?

O `btoa` é uma API de 1995 que só aceita caracteres no intervalo de byte 0–255. Chamar `btoa('São Paulo')` dispara InvalidCharacterError. O caminho correto é `btoa(String.fromCharCode(...new TextEncoder().encode(input)))`, que é o que esta ferramenta faz internamente. O TextEncoder produz bytes UTF-8, e o `btoa` recebe uma string binária desses bytes.

Base64 aumenta o tamanho dos dados?

Aumenta — em exatamente 33% para o payload codificado (3 bytes entram, 4 chars saem), mais até 2 chars de padding, mais 2 chars a cada 76 chars de entrada quando aplicado o quebra-linha MIME. Para um arquivo de 1 MB isso significa cerca de 1,33 MB codificado, ou 1,37 MB com quebra MIME. Se o tamanho importa, comprima (gzip) antes de codificar, não depois — Base64 comprimido é quase incompressível.

Base64 é case-sensitive?

Sim. O alfabeto trata `A` e `a` como caracteres distintos. `SGVsbG8=` decodifica para "Hello"; `sgvsbg8=` decodifica para algo aleatório. Se você precisa de transporte case-insensitive, o Base32 (RFC 4648 §6) é a alternativa canônica — ao custo de 60% de overhead em vez de 33%.

O decodificador rejeitou minha entrada. O que pode estar errado?

Três suspeitos usuais. (1) A entrada foi copiada de um contexto que estragou o alfabeto — trocando `+` por espaço, tirando `=`, ou cortando a string com espaços extras. Esta ferramenta tolera espaço em branco e auto-padding, mas caracteres genuinamente perdidos não dá pra recuperar. (2) Os bytes não eram texto. Decodificar Base64 de PNG ou blob binário e forçar por um decoder UTF-8 vai parecer lixo; não é bug, a origem é binária. (3) O tamanho é matematicamente impossível — Base64 length mod 4 deve ser 0, 2 ou 3, nunca 1.

No Open Finance BR, por que vejo Base64URL nos tokens e Base64 padrão nos anexos?

Convenção do canal. Os tokens JWS/JWE da especificação Open Finance Brasil seguem a RFC 7515/7519, que mandam Base64URL sem padding nos três segmentos. Já anexos binários (PDF de termo, imagem de comprovante, XML de NF-e) viajam em Base64 padrão com padding dentro de campos JSON. Quando um decoder reclama de input inválido nesse contexto, o primeiro check é padding/alfabeto coerente com o canal.