Validador de Base64

Base64: a codificação binário-texto por trás de data URIs, JWTs e anexos de email

Base64 é o esquema de codificação binário-para-texto que converte bytes arbitrários em uma string ASCII imprimível usando um alfabeto de 64 caracteres. Padronizada pela RFC 4648 (2006, sucessora da RFC 3548) e introduzida originalmente para o padrão de email MIME na RFC 2045 (1996), continua sendo o cavalo de batalha para transportar dados binários por sistemas que só entendem texto: cabeçalhos SMTP, JSON, XML, cookies HTTP, assinaturas JWT e atributos HTML.

O custo é tamanho: cada 3 bytes de entrada viram 4 caracteres de saída, com 33% de overhead. O ganho é universalidade: uma string base64 sobrevive intacta a qualquer pipeline ASCII de 7 bits, sem escaping nem corrupção.

Alfabeto padrão vs base64url

O alfabeto padrão definido pela RFC 4648 usa A-Z, a-z, 0-9, + e / — 64 caracteres no total. O sinal = é reservado para o padding no fim (1 ou 2 caracteres dependendo do tamanho da entrada).

A variante base64url (também RFC 4648, seção 5) troca os dois caracteres problemáticos: + vira - e / vira _, deixando a string segura para URLs, nomes de arquivo e cabeçalhos HTTP sem percent-encoding. O padding também é opcional em base64url, por isso JWTs nunca carregam = no final.

Regex de validação e a regra do módulo 4

Uma string base64 padrão bem formada casa com ^[A-Za-z0-9+/]*={0,2}$ e seu tamanho deve ser múltiplo de 4. Para base64url a regex é ^[A-Za-z0-9_-]*={0,2}$ e a restrição de tamanho relaxa quando o padding é omitido (tamanho mod 4 = 2 ou 3).

O tamanho da saída para n bytes de entrada é ceil(n / 3) * 4 caracteres. Decodificando ao contrário: uma string padrão de 100 caracteres carrega entre 73 e 75 bytes dependendo do padding.

Armadilhas comuns ao validar Base64

• Alfabetos misturados: um segmento de JWT contém - ou _ e falha na regex padrão. Tente os dois alfabetos antes de declarar inválido.
• Padding ausente: legal em base64url, ilegal no Base64 padrão estrito. Alguns parsers toleram, outros não.
• Quebra de linha MIME: a RFC 2045 insere um CRLF a cada 76 caracteres. Remova whitespace antes de validar.
• Fonte Unicode: btoa() no navegador só aceita Latin-1. Para texto UTF-8 é preciso codificar antes com TextEncoder e então base64 dos bytes.
• Payload truncado: sintaxe válida não garante decode válido. Tente o decode para confirmar integridade semântica.

Casos de uso reais

• Data URIs: data:image/png;base64,iVBORw0KGgo... embute imagens diretamente em HTML/CSS.
• JWT (JSON Web Tokens): header, payload e assinatura são segmentos base64url separados por pontos.
• HTTP Basic Auth: Authorization: Basic dXNlcjpwYXNz é base64(user:pass).
• Anexos de email (MIME): base64 embrulha PDFs, imagens e binários dentro de SMTP só-texto.
• SVG embutido, fontes e Web Workers: qualquer asset binário inline em arquivo textual.
• Cookies e localStorage: pequenos blobs binários (às vezes gzip-depois-base64) armazenados no cliente.

Performance e bibliotecas

Navegadores trazem btoa() e atob() nativos, mas só operam em strings ASCII — Unicode exige TextEncoder/TextDecoder. Node.js usa Buffer.from(str, 'base64') e buf.toString('base64'), que tratam bytes diretamente e são altamente otimizados. Bibliotecas populares incluem base64-js e js-base64 para codificação cross-environment Unicode-aware.

FAQ

Validar Base64 é fácil?

Validação de sintaxe é simples — alfabeto mais tamanho-mod-4 mais checagem de padding. Validação semântica (decodifica em algo significativo?) exige tentar o decode e inspecionar os bytes.

O que é a variante URL-safe?

É a base64url, definida na seção 5 da RFC 4648. Troca + por - e / por _, permitindo o uso em URLs, nomes de arquivo e cabeçalhos HTTP sem percent-encoding.

Uma string Base64 pode ser válida sem padding?

No Base64 padrão estrito da RFC 4648, não — o padding é obrigatório. Em base64url (e em muitas implementações práticas), sim — o padding é opcional. JWTs são o exemplo canônico de base64url sem padding.

Por que o overhead é de 33%?

Porque cada caractere base64 carrega 6 bits de informação (2^6 = 64), enquanto cada byte carrega 8 bits. Para codificar 3 bytes (24 bits) são necessários 4 caracteres (24 bits), portanto 4/3 = 1,33x o tamanho original.

Devo aplicar gzip antes do Base64?

Se o payload é grande e compressível (JSON, XML, texto), DEFLATE-depois-base64 pode reduzir drasticamente a string transportada — comum em cookies e estratégias de cache HTTP. Para dados já comprimidos (PNG, JPEG, ZIP), só adiciona custo de CPU.