Base64 Encoder e Decoder

O Base64 nasceu de um problema muito concreto: como transmitir dados binários por sistemas que só entendiam texto ASCII de 7 bits. No final dos anos 1980, o e-mail era o principal meio de comunicação digital, e o protocolo SMTP foi projetado para trafegar apenas texto simples. Arquivos binários — imagens, executáveis, documentos — corrompiam ou simplesmente desapareciam no trânsito. A solução foi o padrão MIME, formalizado no RFC 1341 de 1992 e revisado no RFC 2045 de 1996, que incluiu o Base64 como mecanismo de codificação padrão. A lógica é elegante: cada grupo de 3 bytes (24 bits) é dividido em quatro grupos de 6 bits, e cada grupo de 6 bits é mapeado para um dos 64 caracteres ASCII seguros — A-Z, a-z, 0-9, + e /. O resultado é 33% maior que o original em bytes, mas pode atravessar qualquer sistema de texto sem corrupção.

Hoje o Base64 está em todo lugar, quase sempre invisível. JWTs são três blocos Base64URL separados por pontos — o cabeçalho, o payload e a assinatura ficam legíveis para qualquer pessoa que decodifique o string, o que é um lembrete constante de que Base64 não oferece sigilo. Data URIs em CSS e HTML incorporam imagens e fontes diretamente no documento: `data:image/png;base64,iVBOR...` — útil para eliminar requisições HTTP extras em ícones pequenos. O HTTP Basic Auth codifica credenciais em Base64 no cabeçalho `Authorization: Basic dXNlcjpzZW5oYQ==` — e decodificar esse valor mostra a senha em texto plano, daí a obrigatoriedade de HTTPS. Chaves SSH públicas em `~/.ssh/authorized_keys`, certificados TLS em formato PEM, payloads de webhooks com anexos binários — todos usam Base64.

A confusão mais comum com Base64 é tratá-lo como segurança. Base64 de senha é senha em texto plano com etapa extra de teatro. Qualquer desenvolvedor com `atob()` no console do navegador ou `base64 -d` no terminal decifra em segundos. O Base64URL, variante usada em JWTs e URLs OAuth, substitui + por - e / por _ e remove o padding = para que o string possa aparecer em parâmetros de URL sem codificação adicional. O padding com = no final do Base64 padrão existe porque o algoritmo processa grupos de 3 bytes: quando a entrada não é múltipla de 3, um ou dois = são adicionados para completar o bloco. Esta ferramenta processa tudo no navegador, sem enviar dados ao servidor — útil para inspecionar tokens JWT, payloads de API ou qualquer string que você suspeite estar em Base64.

Base64 was born from a very concrete problem: how to transmit binary data over systems that only understood 7-bit ASCII text. In the late 1980s, email was the primary means of digital communication, and the SMTP protocol was designed exclusively for plain text. Binary files — images, executables, documents — would corrupt or simply disappear in transit. The solution was the MIME standard, formalized in RFC 1341 in 1992 and revised in RFC 2045 in 1996, which included Base64 as the standard encoding mechanism. The logic is elegant: each group of 3 bytes (24 bits) is split into four 6-bit groups, and each 6-bit group is mapped to one of 64 safe ASCII characters — A-Z, a-z, 0-9, + and /. The result is 33% larger than the original in bytes, but can travel through any text-based system without corruption.

Today Base64 is everywhere, almost always invisible. JWTs are three Base64URL blocks separated by dots — the header, payload, and signature are readable by anyone who decodes the string, a constant reminder that Base64 provides no secrecy. Data URIs in CSS and HTML embed images and fonts directly in the document: `data:image/png;base64,iVBOR...` — useful for eliminating extra HTTP requests for small icons. HTTP Basic Auth encodes credentials in Base64 inside the `Authorization: Basic dXNlcjpzZW5oYQ==` header — decoding that value reveals the password in plain text, which is precisely why HTTPS is mandatory when using it. SSH public keys in `~/.ssh/authorized_keys`, TLS certificates in PEM format, webhook payloads with binary attachments — all use Base64.

The most common confusion about Base64 is treating it as security. A password encoded in Base64 is a password in plain text with an extra theatrical step. Any developer with `atob()` in the browser console or `base64 -d` in the terminal can decode it in seconds. Base64URL, the variant used in JWTs and OAuth URLs, replaces + with - and / with _ and removes the = padding so the string can appear in URL parameters without additional encoding. The = padding at the end of standard Base64 exists because the algorithm processes groups of 3 bytes: when the input is not a multiple of 3, one or two = signs are added to complete the block. This tool processes everything in the browser, without sending data to the server — handy for inspecting JWT tokens, API payloads, or any string you suspect is Base64-encoded.

El Base64 nació de un problema muy concreto: cómo transmitir datos binarios por sistemas que solo entendían texto ASCII de 7 bits. A finales de los años 1980, el correo electrónico era el principal medio de comunicación digital, y el protocolo SMTP fue diseñado exclusivamente para texto plano. Los archivos binarios — imágenes, ejecutables, documentos — se corrompían o simplemente desaparecían en tránsito. La solución fue el estándar MIME, formalizado en el RFC 1341 de 1992 y revisado en el RFC 2045 de 1996, que incluyó el Base64 como mecanismo de codificación estándar. La lógica es elegante: cada grupo de 3 bytes (24 bits) se divide en cuatro grupos de 6 bits, y cada grupo de 6 bits se mapea a uno de los 64 caracteres ASCII seguros — A-Z, a-z, 0-9, + y /. El resultado ocupa un 33% más que el original en bytes, pero puede atravesar cualquier sistema de texto sin corromperse.

Hoy el Base64 está en todas partes, casi siempre invisible. Los JWT son tres bloques Base64URL separados por puntos — la cabecera, el payload y la firma son legibles para cualquiera que decodifique el string, lo que es un recordatorio constante de que Base64 no ofrece confidencialidad. Los data URIs en CSS y HTML incrustan imágenes y fuentes directamente en el documento: `data:image/png;base64,iVBOR...` — útil para eliminar solicitudes HTTP adicionales en iconos pequeños. El HTTP Basic Auth codifica credenciales en Base64 dentro del encabezado `Authorization: Basic dXNlcjpzZW5oYQ==` — decodificar ese valor revela la contraseña en texto plano, de ahí la obligatoriedad de HTTPS. Las claves SSH públicas en `~/.ssh/authorized_keys`, los certificados TLS en formato PEM, los payloads de webhooks con archivos adjuntos binarios — todos usan Base64.

La confusión más común con Base64 es tratarlo como seguridad. Una contraseña codificada en Base64 es una contraseña en texto plano con un paso teatral adicional. Cualquier desarrollador con `atob()` en la consola del navegador o `base64 -d` en la terminal la descifra en segundos. Base64URL, la variante usada en JWT y URLs de OAuth, reemplaza + por - y / por _ y elimina el relleno = para que el string pueda aparecer en parámetros de URL sin codificación adicional. El relleno con = al final del Base64 estándar existe porque el algoritmo procesa grupos de 3 bytes: cuando la entrada no es múltiplo de 3, se añaden uno o dos = para completar el bloque. Esta herramienta procesa todo en el navegador, sin enviar datos al servidor — útil para inspeccionar tokens JWT, payloads de API o cualquier string que sospeches que está codificado en Base64.